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1 INTRODUCTION 


This manual provides a high-level overview of the Physical Input/Output 
(I/O) function on Burroughs computer systems that support Universal I/0 
(UIO) on Message-Level Interface Processor (MLIP) systems (A 3, A 3K, 
A 9, A 10, B 5900, and B 6900). This manual is primarily intended as an 
introduction for systems programmers who will later study the software 
implementation of Physical I/O, but it may also be of interest to those 
for whom an overview of the major components involved in the I/O process 
is sufficient. It is assumed that the reader is familiar with the basic 
structure and function of the Master Control Program (MCP) and the New 
Programming (NEWP) language, although knowledge of the details of the 
MCP and of the machine architecture is not required. 


The PHYSICALIO module of the MCP is the central component in the 
Physical I/O process. There are four versions of this module, the 
appropriate one of which is selected during system initialization 
according to the type of I/O subsystem the machine supports: 


deg MLIP (A 3, A 3K, A 9, A 10, B 5900, and B 6900 systems) 

2. Multiplexor (B 6800 systems) 

3. I/O Module (B 7700 and B 7800 systems) 

4. Host Data Unit (HDU) (A 15 and B 7900 systems) 
The four versions of the PHYSICALIO module have the same interface to 
the rest of the MCP, freeing the majority of the MCP from having to 
handle the idiosyncrasies of four different I/O subsystems. Only the 
MLIP module version is described in this manual. 
The systems using the MLIP I/O subsystem are divided into two groups: 

ds The A 3, A 9, B 5900, and B 6900 systems 

2s The A 3K and A 10 systems 
The basic I/O process is the same for these systems, but some of the 
procedures, mechanisms, and data structures used by the MLIP I/0 


subsystem for each group are different. The systems are identified when 
a distinction must be made between the two groups of systems. 


The A 3K system has a dual processor configuration but can function with 
only one processor working. Other A 3 models are single-processor 
systems. 


PHYSICAL I/0 OVERVIEW 
NOTE 


This document is not intended to be a 
complete specification of the Physical 
I/C implementation for MLIP systems. 
Most specific details and exception 
conditions have been omitted for brevity 
anc to better highlight the general 
structure of the I/O software and 
hardware. Although the overall design is 
Stable, tne details of the implementation 
are subject to change from Mark Release 
to Mark Release. 
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STRUCTURE OF THIS MANUAL 


Sections 


a INTRODUCTION 


The purpose of this overview is described, and the PHYSICALIO module 
versions are listed. 


2 SYSTEM OVERVIEW 


The general I/O path between the MCP and the UIO subsystem is 
described and illustrated. 


3 MCP REQUESTORS 


The MCP modules that interface with PHYSICALIO to initiate I/Os and 
to request unit information are described. 


4 REQUESTOR/PHYSICALIO INTERFACE 


Input/Output Control Block (IOCB) and unit interfaces that exchange 
information between the MCP and the PHYSICALIO module are described. 


5 PHYSICALIO MODULE 


PHYSICALIO's responsibilities for I/O processing, exception 
handling, and responding to unit inguiries are described. 


6 PHYSICALIO/MLIP INTERFACE 


The mechanisms that are used to communicate between PHYSICALIO and 
the MLIP are described. The mechanisms and data structures 
described are IOCBs, Communicate with Universal I/O (CUIO) operator, 
Signal Processing Element Set (SPES) operator, IOCB queue, command 
queue, unit queue, MLIP I/O Table, horizontal queve, result queue, 
and I/O Finish interrupt. 


F MLIP 


The functions of the MLIP are listed and MLIP commands are 
daescribed. 
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8 MLIP/UIO INTERFACE 
The Message-Level Interface (MLI) (the mechanism used to allow 
communication between the MLIP and the UIO_ subsystem) and the 
actions performed when an I/O is transferred to a DLP are described. 
9 UIO SUBSYSTEM 
The rules and conventions used to establish a valid UIO subsystem 
configuration are described. The host, UIO base, Data Link 
Processor (DLP), unit, and path are identified as parts of a JUIO 
subsystem configuration. 
10 SYSTEM INITIALIZATION 
The initialization procedures for the UIO subsystem are described. 
11 PERIPHERAL STATUS 
The method of monitoring a peripheral's status is described. 
12 DATA COMMUNICATIONS 
Data communication nandled by special-purpose DLPs--Network Support 
Processors (NSPs), Line Support Processors (LSPs), and Data 
Communications Data Link Processors (DC-DLPs)--in the I/O subsystem 
is described. 
Appendix 


A glossary appears at the end of this manual. 
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RELATED DOCUMENTS 


Document Form No. 


Operator Display Terminal (ODT) Reference Manual 1169612 


2 SYSTEM OVERVIEW 


The PHYSICALIO module is the Master Control Program's (MCP) interface to 
the I/O subsystem. PHYSICALIO provides two notable functions relating 
to the I/O subsystem: the handling of I/Os and the management of units. 
Units are peripheral devices such as printers, magnetic tape drives, 
card readers, and so on. 


MAJOR COMPONENTS 


Figure 1 shows the basic flow of information between the MCP and the I/0 
subsystem: 


_-_ = =-—=§ -—|-= — — ewe ere ee —-— —_ = 


| Message-Level Interface Processor (MLIP) | 


| Universal I/O (UIO) Subsystem | 


Figure 1. Information Flow between MCP and UIO Subsystem 


PHYSICAL I/O OVERVIEW 
Most I/Os follow this standard path through the system: 


dey An MCP requestor calls the PHYSICALIO module to perform a 
specific I/O operation. 


ar The PHYSICALIO module builds a data structure representing the 
operation to be performed and calls the MLIP. 


oe The MLIP interprets the data structure, generates an I/O 
request, and passes it to the UIO subsystem. 


The results of the I/O ‘follow the reverse path, from the UIO subsystem 
to the MLIP to PHYSICALIO to the requestors. 


Each of the components and interfaces shown in Figure 1 will be 
discussed later in the manual. However, because the structure and 
terminology of the UIO subsystem may be unfamiliar to some readers, a 
brief functional description of the UIO subsystem is presented here. 


System Overview 
UIO FUNCTIONAL OVERVIEW 


Figure 2 illustrates the configuration of components used to pass data 
from the MLIP to the UIO bases. 


{Port|Port|Port|Port | 
| | | 
MLI 


eed aad <--| 
| 
| 
| 
B 
A 
leer erca | S 
E 
| 
| 
| 
| 
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|---~- | <-- 
Figure 2. MLIP-to-Ul10-Base Configuration 

Each processor uses an MLIP and associated hardware to pass an I/O to a 
peripheral. The following is a typical I/O path from an MLIP to a DLP. 

Lis MLIP 

2s MLI ports 

3% MLI 

4. UIO base 

Big Data Link Processors (DLPs) 
Each base contains one or more DLPS, which can connect either directly 


to the peripheral or to a peripheral controller (depending on the type 
of peripheral). In addition, each base includes the components 
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PHYSICAL 1/0 OVERVIEW 


necessary to route messages between the DLPs and the host. 


There is, in general, a different type of DLP for each type of 
peripheral. In Figure 3, a Train Printer DLP (TP-DLP) is shown 
connected to a train printer, a Card Reader DLP (CR-DLP) is shown 
connected to a card reader, and a Host Transfer DLP (HT-DLP) is shown 
connected to a Disk Pack Drive Controller (DPDC). 


|Port|Port|Port|Port | 
| | | | 


[=Ssse4 | | Exchange | 
fal] |{e1= | 

Lf | ft tt 

Disk Units 


Figure 3. MLIP-through-DLP Configuration 


Figures 2 and 3 are schematic and do not necessarily represent actual 
configuration possibilities, restrictions, or limits. A more detailed 
description of UIO subsystem configurations is contained in the "UIO 
Subsystem" section of this manual. 


See also 
VIO -SUSSyYSteMm «a. <e“a. So ee ok oe Ree US EP ee SR me Ber ee Se ra, we cP a OTS 
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MCP REQUESTORS 


The PHYSICALIO module provides the following services to the rest of the 
Master Control Program (MCP): maintaining unit information, initiating 
I/Os, monitoring peripheral status, and initializing Data Link 


Processors (DLPs). This section describes the MCP modules that 
interface with PHYSICALIO to initiate I/Os and to request unit 
information. Peripheral status and system initialization are described 


in later sections. 


See also 
Peripnerad, Stabs ai 22 sé seek Beg, ae oe Gee ee ee SY a os Ge ee Yes Ver ee OO 
System: InttialiZataon:  -o.ce: cds et Bes Ve ee Bn RS we er OS oe a ee, BZ 


1/0 REQUESTORS 


All I/Os required by the MCP, except some I/Os performed early in the 
system initialization process, are initiated by calling the PHYSICALIO 
module. The programmatic mechanism of communication between the 
requesting modules shown in Figure 4 and the PHYSICALIO module is 
described in the next section. 


MCP I/O Requestors 


| Logical I/0 Memory Manager Library Maintenance | 
Dreieteecerenereterednn eterna cetera | 
| Task Manager | Maintenance | AUTOBACKUP | 
J 0 eeeeena---- | ----------- | ---------- | 
| Other | Datacomm | | Job Controller | 
| Modules.) «ss —>s> | || Sere ee ass | Sort 


Figure 4. PHYSICALIO and Requesting Modules 
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PHYSICAL I/O OVERVIEW 


Although there are many inmodules that call PHYSICALIO, PHYSICALIO views 
these requestors as members of certain categories or sets. These sets 
are based on the distinctions required to properly handle the I/0 
request, not on the identity or function of the module requesting the 
I/O. Some distinctions :shat PHYSICALIO makes based on the type of 
requestor are whether or not to allow access to privileged information 
or operations, whether o7 not to attempt error recovery, and whether or 
not to log errors. 


As far as PHYSICALIO is vconcerned, all I/Os fall into one of four main 
I/O requestor sets: 


I/O Set Description 


User I/Os initiated on behalf of a user program. Logical 
I/O and library maintenance are two areas in the MCP 
that request user I/Os. 


MCP The general category of 1/0s initiated to perform MCP 
functions. Memory management, SWAPPER, Datacomm, and 
AUTOBACKUP request MCP I/Os, as do many other 
functions in the MCP. 


Maintenance I/Os initiated primarily by the maintenance module to 
perform I/O hardware diagnostic functions. 


Kernel I/Os initiated by PHYSICALIO itself to perform such 
functions as retrying errors and determining 
peripneral status. 


Because a value representing the type of requestor is passed to 
PHYSICALIO with each I/O request, a requesting module can initiate I/Os 
with different requestor values for different purposes. For example, 
the maintenance module initiates maintenance I/0s when it performs 
diagnostic tests and use: I/Os (through logical I/O) when it displays 
the results of those teszs. 


The four main I/O reques<or sets (described above) comprise several 
specific requestor values. These values allow PHYSICALIO to make more 
specialized distinctions when desirable and can be regrouped into 
additional sets. 
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MCP Requestors 


When the distinction between user I/Os and MCP I/Os is important (for 
example, in exception handling), PHYSICALIO tests the requestor value 
for membership in either the user I/O set or the MCP I/O set. 


When special handling is required for library maintenance I/Os (for 
example, in retrying parity errors), PHYSICALIO tests the requestor 
value for membership in the library maintenance I/O set. 


PHYSICAL I/O OVERVIEW 


UNIT INFORMATION REQUES:'TORS 


Many of the same modules that request I/Os to be performed also require 
information about anc/or some control over the units to which the I/Os 
are sent. Some of trese requestors are Logical I/0, Maintenance, 
Datacomm. and AUTOBACKUP. In addition, some modules are functionally 
related to PHYSICALIO in that they maintain information about the status 
of units and the configuration of the I/O subsystem. Much of this 
information is "logical," as opposed to "physical," in nature and, thus, 
is appropriately mairtained outside of PHYSICALIO. Three modules that 
maintain such information are described below. 


FILEFINDER Module 


The FILEFINDER module locates an input or output device upon request. 
FILEFINDER maintains the UNIT table, which contains data about each 
uni t- Although most of the information is updated during the 
performance of other logical functions (such as reading labels, 
assigning units to tasks, and reserving units), information pertaining 
to the current physical status of a unit is obtained by calling 
PHYSICALIO. 


UNITID Module 


The UNITID module reads and writes labels on labeled units. These 
functions require that UNITID request unit information from PHYSICALIO. 
UNITID maintains the UINFO table, which contains label information for 
each unit. 


MCPSTATUS Module 


The MCPSTATUS module displays and alters unit information through the 
SYSTEMSTATUS, GETSTATUS, and SETSTATUS interfaces. These functions 
require that MCPSTATUS call PHYSICALIO to obtain and to alter 
unit-oriented information. 


Other functional areas that require unit information include disk 
allocation, disk file management, directory control, and configuration 
control. 


LD 
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REQUESTOR/PHYSICALIO INTERFACE 


The Master Control Program (MCP) requestors exchange information with 
the PHYSICALIO module through a group of interface procedures that are 
exported by the PHYSICALIO module. The names of these procedures are 
identical for all four PHYSICALIO version modules, so that the majority 
of the MCP is not required to distinguish between the possible I/0 
subsystems. 


The two primary categories of interface procedures are Input/Output 
Control Block (IOCB) interfaces and unit interfaces. 


IOCB INTERFACE PROCEDURES 


The 1/0 request interface between PHYSICALIO and the Message-Level 
Interface Processor (MLIP) is a data structure called an _ IOCB. 
PHYSICALIO allocates and manages IOCBs, which allows the format of IOCBs 
and the mechanism for their allocation to vary without impact on the 
rest of the MCP. Some of the information required in the I0CB is 
provided by the requestor through interface procedures and some is 
inserted by PHYSICALIO before actually starting the I/O. After 
processing the I/0, the MLIP places result information into the IOCB; 
PHYSICALIO interprets this information and generates a logical result 
descriptor, which is accessible to the requestor through an interface 
procedure. 


As far as the requestor is concerned, there are three stages in the I/0 
process: 


ge Allocating the IOCB 
oe Performing one or more I/Os using that IOCB 
ce Deallocating the IOCB 


Performing I/Os involves providing the proper parameters to PHYSICALIO 
and acting on the result information. The following pages describe the 
interface procedures provided for IOCB-related actions. 
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Setting Up an IOCB 


IOCBs are allocated when the requestor calls BUILDIOCB. BUILDIOCB 
stores a "“mom" descripzor of the new IOCB in a location specified by a 
reference passed as a parameter to BUILDIOCB. To initiate the I/O once 
the IOCB has been allocated, the requestor must provide PHYSICALIO with 
the following information: 


- A reference to the IOCB 


- An I/O Control Word (I0CW) describing the operation to be 
performed 


- A buffer for the data 


- An offset into the buffer indicating the start of the area 
available for possible data transfer 


- The length of the area available for possible data transfer 


- A mask with bits set to indicate the exception conditions under 
which PHYSICALIO is not to attempt recovery 


- The unit number of the unit to which the I/O is to be directed 


- A value representing the requestor type 


If the I/O is to be performed asynchronously (that is, while the 
requestor continues executing), another piece of information is 
required: 


- A reference to an event to be caused when the I/O has finished 


If the I/O is a user I/O, an additional parameter is required: 


- A reference to the File Information Block (FIB) of the IOCB 


Because information chanzes from one I/O to the next in most cases, all 
of this information is passed to PHYSICALIO when I/O initiation is 
requested. However, in 3ome cases, most notably for normal (nondirect) 
user I/Os requested th:ough logical I/O, the information is relatively 
constant from one I/O operation to the next. several interface 
procedures are provided to allow many of the I/O parameters to be set 
before the I/O initiation is requested; thus, information for the IOCB 
jis transferred only when it changes. 
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Requestor/PHYSICALIO Interface 


For a requestor such as logical I/O, the interface procedures called 
"SET<item>" (such as SETIOMASK) would be called between I/Os to alter 
only the IOCB information that must change before the next I/O. The I/O 
initiate procedure for these I/0s (described in "Initiating an I/0") 
requires very few parameters because most of the information has already 
been stored in the IOCB. 


Initiating an I/O 


Many interface procedures are provided for initiating I/Os. The most 
important characteristics of each procedure can be readily identified by 
each procedure name. 


The first part of each procedure name is either INITIATE or Do. 
INITIATE procedures initiate an I/O asynchronously; that is, control is 
returned to the requestor after the I/O is initiated without waiting for 
the I/O to finish. DO procedures initiate an I/O and wait until the I/O 
finishes before returning control to the requestor. 


The second part of each procedure name contains one or more of the 
following keywords: 


Keyword Type of I/0 

CHAR A character-oriented I/0 
WORD A 48-bit-word-oriented I/0 
MEMORY A 51-bit-word-oriented I/O 
USER A user I/0 


MAINTENANCE A maintenance I/0 
DIRECT A direct I/O 


PSEUDO An I/O not actually to be performed; the requestor is 
calling PHYSICALIO just for bookkeeping purposes 


KERNEL A kernel I/0 


"IO" is appended to complete the procedure name. 
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PHYSICAL I/O OVERVIEW 
Not all combinations of these keywords represent actual interface 
procedures because many of the combinations are not required. The 
following identifiers «are examples of I/O initiation interface 
procedures: DOCHARIO, DOMEMORYIO, INITIATEUSERIO, INITIATEUSERDIRECTIO, 
INITIATEDIRECTPSEUDOIO. 


Accessing Information in an JOCB 


The information in an IOUCB cannot be accessed or changed while the 1/0 
is in process, A Boolean interface procedure called IOINPROCESS allows 
the requestor to determijie whether or not the I/O is still active. 


If the I/O is not in process, various items stored in the IOCB can be 
requested through the "GET<item>" interface procedures. For example, 
GETIOTIME returns the I/D time stored in the IOCB. GETLOGICALRESULT 
returns a "soft" resilt descriptor that is common for all I/O 
subsystems. This result is Similar in content to the STATE file 
attribute. 


Deallocating an IOCB 


An IOCB is deallocated by calling the interface procedure FORGETIOCB. 
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Requestor/PHYSICALIO Interface 


UNIT INTERFACE PROCEDURES 


The unit interface procedures allow PHYSICALIO and the requestors to 
exchange information about the status and visibility of the I/O units. 
Information about a particular unit is requested by specifying a unit 
number, as described below. 


Each unit has two unique unit numbers: a logical unit number and a 
physical unit number. Logical unit numbers are used within the MCP for 
two major reasons: 


1. Logical unit numbers refer only to units for which there is a 
Data Link Processor (DLP) physically present (rather than 
referring to the entire tree of addressable units). This makes 
the UNIT tables much smaller than they otherwise might be. 


2. Logical unit numbers allow a physical unit to "move" without 
affecting its logical connection to the MCP. 


Physical unit numbers are used when the MCP communicates with the system 
operator or the I/0 subsystem. PHYSICALIO maintains the correspondence 
between logical and physical unit numbers. 


The following paragraphs describe some of the major unit interface 
procedures. 


TAKEUNIT and GIVEUNIT 


TAKEUNIT and GIVEUNIT are important interfaces for coordinating the 
transfer of a unit's logical control from PHYSICALIO to its requestors 
(TAKEUNIT) and from the requestors back to PHYSICALIO (GIVEUNIT). 


For single-user devices (for example, train printers), TAKEUNIT is 
called when the unit is assigned to a task and GIVEUNIT is called when 
the unit becomes unassigned. For multiple-user devices (for example, 
disk packs), TAKEUNIT is called before the label is read and GIVEUNIT is 
called in response to an Operator Display Terminal (ODT) command (such 
as CLOSE and UR). 


Two of the parameters to GIVEUNIT indicate whether or not PHYSICALIO 
monitors peripheral status for the unit and, if so, whether or not the 
unit is logically ready. The initiation of peripheral status monitoring 
is described in the "Peripheral Status" section. 
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GETUNITINFO and SETUNITINFO 


These procedures allow the requestors to access and, in some cases, 
alter various items of unit information. For example, GETUNITINFO will 
return the unit's subtype, an indication of whether or not there is a 
path to the unit, or the unit's reliability factor, depending on the 
item requested by the procedure's selection parameter. 


GETLOGICALUNITSTATUS 


This procedure returns jJevice-dependent information about the unit; for 
a train printer, for example, GETLOGICALUNITSTATUS will indicate whether 
or not a TRAIN table has been loaded, and for a magnetic tape, whether 
or not the tape is rewinding. 


See also 
Peripneral *Statuse + wh gto Wedd S, ae ew Be ee OS ce Mees 2 wp Rs. SL 
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5 PHYSICALIO MODULE 


The PHYSICALIO module participates in system initialization by creating 
and maintaining the configuration tables describing the I/O subsystem. 
This topic is described in the "System Initialization" section. 
PHYSICALIO also monitors peripheral status, which is discussed in the 
“Peripheral Status" section. PHYSICALIO's responsibilities in the areas 
of I/O processing, exception handling, and responding to inquiries about 
units are described in the following paragraphs. 


PROCESSING OF I/Os 


The PHYSICALIO module provides two methods of I/0 initiation for the 
Message-Level Interface Processor (MLIP) I/O subsystem. 


Ls One method supports the A 3, A 9, B 5900, and B 6900 systems. 
25 The other method supports the A 3K and A 10 systems. 
Both methods of I/O initiation are discussed in this section. The 


systems are identified when the I/O processing method is unique to a 
systems group. 


At initialization time, the Master Control Program (MCP) interrogates 
the result of the WATI operator to determine which I/O method is used on 
the system. The WATI operator identifies the system in use and provides 
implementation-level information about the system. 


The result of the WATI operator determines which I/O initiation method 
to use for the system. The I/O initiation method in turn determines 
whether or not the Communicate with Universal I/O (CUIO) operator is 
valid for the system. The CUIO operator is used to pass the address of 
an Input/Output Control Block (IOCB) to an MLIP for initiation. The 
CUIO operator is used in the A 3, A 9, B 5900, and B 6900 systems and is 
described in "CUIO Operator." On A 3K and A 10 systems, an I/O is issued 
by queuing an IOCB to an IOCB queue and using the Signal Processing 
Element Set (SPES) operator to signal the MLIP. The SPES operator is 
described in the "PHYSICALIO/MLIP Interface" section. 
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I/O Processing for A 3, A 9, B 5900, and B 6900 Systems 


The I/O processing method for A 3, A 9, B 5900, and B 6900 systems 
through the PHYSICALIO module is described by the following example. 
INITIATECHARIO was chosen as the interface procedure for the 1/0 
initiation example because it is a commonly used interface for MCP I/Os. 
At decision points in the processing, the most straightforward choice is 
taken. For example, :t is assumed here that the I/O was completed 
without exceptions (exception handling is described in "Exception 
Handling"). 


Example 

Ly After allocating an IOCB through BUILDIOCB, the requestor calls 
INITIATECHARIO, passing in the following required parameters: 
a. The IOCB 
jon A reference to the event to be caused when the I/O 

finishes 
om The requestor type 
d. An I/O exception mask 
e. An Input/Output Control Word (I0CcW) 
f°. A buffer 
g An index into the buffer 
hs An I/O length 
is A unit number 

ae INITIATECHARIO marks the IOCB "in process," stores the 
parameters in the IOCB, and calls INITIATEIO. 

ci INITIATEIO coordinates the remainder of the I/0 initiation 
processing by calling SETUPIOCB, GETPATH, and FIREIOCB. 

4. SETUPIOCB converts the IOCW into the appropriate operation code 
for the Universal I/0 (UIO) subsystem and sets up the 
information required for the proper queuing of the IOCB by the 
MLIP. 

oe GETPATH selects a path to the unit and inserts the path 


information into the IOCB. 
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Ox FIREIOCB marks the IOCB “active” and gives the IOCB to the MLIP 
through the CUIO operator. 


The I/O is now in progress. The following actions occur when the MLIP 
informs the MCP that the I/O has been completed. 


Fae HARDWAREINTERRUPT is invoked when the I/O Finish interrupt is 
received from the MLIP: HARDWAREINTERRUPT calls IOFINISH68. 


Because the 1/0 Finish interrupt does not designate which I/0 
has completed, IOFINISH68 searches through the result queues to 
find completed I/Os. When one is found, IOFINISH68 selects the 
appropriate routine to handle the completed 1/0; in most cases 
(in particular, when there are no exceptions reported), it 
calls FINISHIO. 


&. FINISHIO determines whether or not it is running on the 
processor that initiated the I/O. If so, it calls FINISHOFFIO. 


O5 FINISHOFFIO inserts into the logical result descriptor a value 
indicating the number of units transferred, computes and bills 
the I/O time, sets the state of the IOCB to "inactive," and 


causes the I/O completion event, a reference to which was 
passed aS a parameter to the interface procedure. 


At this point, the requestor has been notified that the I/O has 
completed and it can now access result information in the IOCB. 


See also 
17 OS Finish: IACerrupts @ smc Hk ok 4 te: ie RE EA ok A we Re SS VE 


I/O Processing for A 3K and A 10 Systems 


The I/O processing method for A 3K and A 10 systems is similar to the 
method described above, except that the procedure names are different 
and additional procedures were created. The procedures that perform the 
same functions as the method above are INITIATEIO_ASIO, FIREIOCB_ASIO, 
and IOFINISH_ASIO. INITIATEDATACOMIO_ASIO and PATHRES_ASIO are new 
procedures that perform ancillary functions for data communication 
operations and path reservation. 


In the following example, the requestor calls INITIATECHARIO for I/O 
initialization. As in the example above, the same parameters are passed 
to the allocated IOCB. 
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Example 


1. INITIATECHARIO marks the IOCB in process, stores the parameters 
in the IOCB, and calls INITIATEIO_ASIO. 


2s INITIATEIO_ASIO coordinates the remainder of the I/O initiation 
processing by calling SETUPIOCB. The path to the peripheral 
device is either specified by GETPATH or determined by the 
optimization defines. When the path is selected, FIREIOCB_ASIO 

is called. 


SETUPIOCB converts the IOCW into the appropriate operation code 
for the UIO subsystem and sets up the information required for 
the proper queuing of the IOCB by the MLIP. 


Ww 
° 


4. The path to a peripheral device can be selected by the MCP 
through GETPATH, or if the Simple Path Selection field in the 
MLIP Control Word of the IOCB is set to TRUE, then the MLIP 
uses the path specified in the Path Table Pointer word of the 
unit queue. I GETPATH is used, the path information is 
inserted into «he IOCB. 


aie FIREIOCB_ASIO marks the IOCB "active" and gives the IOCB to the 
MLIP by queuinz it in the IOCB queue. 


The I/O is now in progress. The following actions occur when the MLIP 
informs the MCP that the 1/0 has completed. 


6. HARDWAREINTERRUPT is invoked when the I/O Finish interrupt is 
received from the MLIP; HARDWAREINTERRUPT calls IOFINISH_ASIO. 


Because the I/O Finish interrupt does not designate which I/0 
has been completed, IOFINISH_ASIO searches through the result 
queues to find completed I/Os. When one is found, IOFINISH_ASIO 
selects the appropriate routine to handle the completed I/0; in 
most cases (in particular, when there are no exceptions 
reported), it calls FINISHIO. 


7. FINISHIO calls FINISHOFFIO. 


8. FINISHOFFIO inserts into the logical result descriptor a value 
indicating the number of units transferred, computes and bills 
the I/O time, sets the state of the IOCB to "inactive," and 
causes the I/O completion event, a reference to which was 
passed aS a parameter to the interface procedure. 


At this point, the requestor has been notified that the I/O has 
completed and it can now access result information in the IOCB. 


See 


also 
I/O Finish Interrupt. 
IOCB. 
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EXCEPTION HANDLING 


The following paragraphs describe how PHYSICALIO handles I/Os that are 
completed with exceptions. The exception-handling mechanism is 
discussed in general terms, ignoring most device dependencies. Although 
handling of device dependencies is really the largest part of the 
exception-handling task, the basic algorithm is similar for most 
devices. For the following situations, the A 3, A 9, B 5900, and B 6900 
systems' I/O subsystem uses IOFINISH68 and the command queue, and the 
A 3K and A410 systems' I/O subsystem uses IOFINISH_ASIO and the unit 
queue. 


Regardless of whether or not’ the I/O is completed normally, 
HARDWAREINTERRUPT calis IOFINISH68 or IOFINISH_ASIO, depending on which 
I/O processing method is used, to handle the I/O Finish interrupt. When 
IOFINISH68 or JIOFINISH_ASIO determines that an exception condition has 
occurred, in most cases it calls IOEXCEPTION to take the appropriate 
action. 


IOEXCEPTION calls BUILDLOGICALRD, which returns a logical result 
descriptor generated by analyzing the physical results received from the 
Data Link Processor (DLP) and the MLIP. Back in IOEXCEPTION, the 
logical result is then masked with the I/O mask that the requestor 
passed as a parameter to the 1/0 initiation procedure; this process may 
eliminate some exception conditions from consideration. The masked 
result is then further masked, this time to eliminate exception 
conditions that do not require handling by PHYSICALIO. 


If no exceptions remain after masking the logical result, IOEXCEPTION 
activates the suspended command queue or unit queue, depending on the 
I/O processing method used by the MLIP I/0 subsystem (see "Command 
Queue" and "Unit Queue"), and calls FINISHIO to complete the processing 
of the IOCB (see “Processing of I/Os"). If the only exceptions that 
remain are simple enough to be handled in IOEXCEPTION (for example, 
end-of-page on a printer), IOEXCEPTION takes the appropriate action. 
However, if a more serious exception remains to be handled, IOEXCEPTION 
Calls IOERROR. 


IOERROR selects a retry procedure based on the type of unit to which the 
Original I/O was directed. The retry procedure retries the I/0 
operation until the operation is successful, until an irrecoverable 
error occurs, or until the retry limit is reached. At this point, 
IOERROR logs the original error and its retry history. In most cases, 
IOERROR then calls FINISHIO to return the IOCB to the requestor and 
activates the command queue or unit queue that was suspended by the MLIP 
because of the original exception. 


PHYSICALIO 


See also 
Command Queue es 
Processing of I/Os... 
Unit Queue. 
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UNIT INFORMATION 


The unit information interface procedures access and alter items in 
PHYSICALIO's unit infovmation tables, the most important of which are 
UNITCONTROL, UNITMAP, and UNITSTATUS. 


UNITCONTROL Table 


The UNITCONTROL table contains information used in making decisions 
about the management of units. This information includes the unit type, 
the "ownership" of the unit (in the TAKEUNIT/GIVEUNIT sense), and 
special status informazion for the unit. GETUNITINFO references this 
table to return information as to whether or not the unit is being 
moved, whether or not the unit has been disabled (through BLASTUNIT), 
whether or not the unit is the Halt/Load unit. whether or not the 
initiation of I/O operations to the unit has been suspended because the 
unit has encountered an end-of-file condition, and so on. 


UNITMAP Table 


The UNITMAP table maintains the correspondence between logical and 
physical unit numbers. When GETUNITINFO is requested to return logical 
or physical unit numbers. it accesses this table. 


UNITSTATUS Table 


The UNITSTATUS table contains the logical and physical ready/not-ready 
status for each unit and the paths to those units. When GETUNITINFO is 
requested to return a va_ue indicating whether or not the specified unit 
exists or whether or not there iS a path to the unit, GETUNITINFO 
accesses this table. 
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6 PHYSICALIO/MLIP INTERFACE 


The Master Control Program (MCP) communicates with the Message-Level 
Interface Processor (MLIP) through the PHYSICALIO module. The A 3, A 9, 
B 5900, and B 6900 systems use the following mechanisms for processing 
I/O between PHYSICALIO and the MLIP: 

- The Communicate with Universal I/O (CUIO) operator 


a Shared data structures, which include Input/Output Control Blocks 
(IOCBs), command queues, horizontal queues, and result queues 


- The I/O Finish interrupt 
The A 3K and A 10 systems use the following mechanisms for _ processing 
I/O between PHYSICALIO and the MLIP: 

- The Signal Processing Element Set (SPES) operator/IOCB queue 


- Shared data structures, which include IOCBs, IOCB queue, unit 
queues, MLIP I/O Tables, horizontal queues, and result queues 


- The I/O Finish interrupt 
The following describes how these mechanisms are used to initiate, 


process, and complete an I/O at the MLIP level for both groups of 
systems. 
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MECHANISMS FOR A 3, A 9, B 5900, AND B 6900 SYSTEMS 


An IOCB represents an I/O operation to be performed. When PHYSICALIO 
has inserted irto an IOCB the information required by the MLIP to 
perform an I/O, the CUID operator is executed to pass the memory address 
of the IOCB to the MLIP. The MLIP then queues the IOCB into a command 
queve, from whick the IDCB is later initiated. If the MLIP attempts to 
initiate an IOCB to a busy Data Link Processor (DLP), the command queue 
may be temporarily linked into a horizontal queue. When an IOCB is 
initiated, it is unlinked from the command queue. When the I/0 
operation associated with an IOCB finishes. the IOCB is linked into a 
result queue. The MLIP then determines whether or not an I/O Finish 
interrupt should be gensrated to inform the processor that an IOCB has 
finished. 


The following data structures are used for PHYSICALIO/MLIP communication 
in the A 3, A 9, B 5900, and B 6900 systems and are set up by the MCP 
for the MLIP: 


- Command queve. A list of IOCBs that are to be initiated, usually 
to the same unit. 


- Horizontal queue. Mechanism for queuing command queues when the 
DLP path to the unit is busy. 


- Result queve. A list of completed IOCBs. A result queue is 
built for each processor. 


The PHYSICALIO/MLIP interfaces are described individually on the 
following pages. Because the handling of MLIP I/O subsystem errors may 
involve all of the interface mechanisms described here, error handling 
is discussed in "MLIP Error Handling," following the descriptions of the 
interfaces. 


See also 
Command “Queue: «i. 2... Soe wes AE Re te te ee a we ae. 
MOPriZontau. OUSNES o6) serge et eae. HES eh ae a es Be ad SB NS Se Ue ce 2B 


RESULt (GUCUe. gos: a Sed “ee Se! ce Se a Se ee bee, He. ee. SEO 


PHYSICALIO/MLIP Interface 


After PHYSICALIO inserts the information required by the MLIP to perform 
an I/O into an IOCB, PHYSICALIO locks the IOCB queue, queues the IOCB to 
the tail of the IOCB queue, and unlocks the IOCB queue. If the IOCB 
queue is empty when the IOCB is queued to it, PHYSICALIO uses the SPES 
operator to send the MLIP an Initiate I/O signal. 


When the MLIP receives the Initiate I/O signal, the signaled MLIP locks 
the IOCB queue, takes the IOCB at the head of the IOCB queue, locks the 
unit queue specified by the IOCB, and then unlocks the IOCB queue. 


If the IOCB queue contains more IOCBs, the MLIP sends the Initiate I/0 
Signal to the other MLIPs specified in the MLIP Destination Set (Word 6) 
of the MLIP I/O table (see "MLIP I/O Table"). The MLIP then queues’ the 
IOCB to the unit queve. If the IOCB is queued at the head of the unit 
queue, the MLIP initiates the unit queue. If the MLIP attempts to 
initiate an IOCB to a busy DLP, the unit queve is temporarily linked 
into a horizontal queue. 


When the I/O is finished, the MLIP puts the IOCB into the appropriate 
result queue. After queuing an IOCB into an empty result queue, the 
MLIP uses the EMP Destination Set (Word 5) of the MLIP I/O table to 
Signal one of the E-Mode processors (EMPs) in the set to handle an I/0 
Finish (see “"MLIP I/O Table"). 


Because processing elements (data and I/O) share data structures, access 
to the data structures is synchronized through a lock bit in the lock 
word of each data structure. 


The IOCB queue is locked by MLIPS and the MCP. All other data 
structures are locked by the MLIP only. After successfully locking and 
using the data structure, the MLIP or MCP writes the lock word back to 
memory, which unlocks the data structure. 


The following data structures are used for PHYSICALIO/MLIP communication 
in the A 3K and A 10 systems and are set up by the MCP for the MLIP: 

- JIOCB queue. Used by PHYSICALIO to send IOCBs to the MLIPs. 

- Unit queue. Allocated such that all I/Os for one unit go through 


the assigned unit queue, regardless of the number of paths to the 
unit. 
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- MLIP I/O table. Contains the MLIP queue and other information 
used by the MLIP. The MLIP uses the MLIP queue to pass unit 
queues to other MLIPs. There is one MLIP queve in each MLIP 1/0 
table and one MLIP I/0 table for each MLIP in the partition. 
There are several words in the table. The EMP and MLIP 
destination set words in the tabie indicate which processing 
elements are available for I/O processing. The other words in 
the table are described when necessary for the overview. 


- Horizontal queue. Mechanism for queuing unit queues when the DLP 
path to the unit is busy. 


- Result queue. A list of completed IOCBs. Only one result queue 
is initialized. 


The MLIP uses disk seek optimization to increase I/O throughput. Disk 
seek optimization is performed during the initiation of the IOCB from 
the unit queue. It selects the IOCB that specifies a disk address 
closest £0 the current position of the disk head. Disk seek 
optimization depends on the single point of control provided by unit 
queues. 


The PHYSICALIO/MLIP interfaces are described individually on the 
following pages. Because the handling of MLIP I/O subsystem errors may 
involve all of the interface mechanisms described here, error handling 
is discussed in "MLIP Error Handling,” following the descriptions of the 
interfaces. 


See also 
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IOCB 


An IOCB is an MCP-allocated memory area that either contains or 
references all of the information required by the MLIP to perform an I/O 
operation. It also contains areas that are used by the MLIP to 
temporarily store information during the processing of an I/O and to 
return information to PHYSICALIO when the I/O has’ finished. This 
information is formatted into the 15 IOCB words shown in Table 1. The 
table also shows which IOCB words are assigned meaningful (nonzero) 
values by the MCP prior to initiation of the IOCB and which are assigned 
values by the MLIP during processing of the IOCB. 


Table 1. I0OCB I/O Table 


Values Assigned by 


MCP MLIP 
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Word 14: | I/0 Finish Time | * 
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The actual IOCB, as allocated by the MCP, is longer than 15 words. The 
additional space is usecl by the MCP to store information about the MCP's 
processing of I/O; for example, a reference to the event to be caused 
when the I/O finishes ig kept in the MCP portion of the IOCB. 


The following describes how each of the 15 MLIP-visible IOCB words, and 
their fields, is used by the MCP andthe MLIP. References to the 
command queue apply to the A 3, A9, B 5900, and B 6900 systems; 
references to the unit queue apply to A 3K and A 10 systems. 


MLIP Control Word 
Word O contains several fields set by the MCP to specify the 
I/O operation to be performed. The fields are described below, 
and an example of the MCP'’s use of each special-purpose field 
is provided. 


IOCB Marz 
This fielcl contains the code 4'10CB', which marks the word 
as the first word of an IOCB. 


Queue at Head 
When this one-bit field is TRUE, the MLIP will queue the 
IocB at the head of the command queue or unit queue. One 
use of this feature is to perform retry I/Os when a 
device-oriented error has occurred. 


MLIP/DLP Commard 
When this one-bit field is TRUE, the I0CB contains a 
command to be interpreted by the MLIP itself; the MLIP 
command ig contained in the first word pointed to by the 
DLP I/0 Command Pointer (Word 4) in the IOCB. The MLIP 
operations that the MCP can request are described in the 
"MLIP" section. 


When this one-bit field is FALSE, the IOCB contains a 
command for the DLP referenced by the DLP Address Word 
(Word 1) cf the IOCB. 


Attention 

When this one-bit field is TRUE, the MLIP will set both 
the Attertion and the Exception fields in the MLIP result 
(see "MLIF State and Result" below). This field forces 
the command queue or unit queue to be suspended upon 
completion of the I/O operation, or ensures that the I/0 
will be processed by the exception handling routines. For 
example, all binary card reads are initiated with the 
Attention field set to TRUE, because IOEXCEPTION is 
responsible for recognizing the binary end-of-file card 
(see "Exception Handling"). 
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Cause I/O Finish Interrupt 
When this one-bit field is TRUE, the MLIP will 
unconditionally cause an I/O Finish interrupt when the I/O 
completes. When this one-bit field is FALSE, the MLIP 
will make the decision as to whether or not to cause an 
interrupt based on other conditions (see "I/O Finish 
Interrupt"). 


Memory Override 
When this one-bit field is TRUE, the MLIP will ignore 
odd-tagged (memory-protected) words in memory during data 
transfer. This field is set to TRUE for I/Os initiated to 
perform memory I/Os for requestors such as PRESENCEBIT and 
SWAPPER. 


Input 
When this one-bit field is TRUE, input from the DLP is 
allowed. 


Output 
When this one-bit field is TRUE, output to the DLP is 
allowed. 


Output Zeros 
When this one-bit field is TRUE, the MLIP will generate a 
data stream of all O's (zeros) to send to the DLP. This 
feature is used only to perform erase operations on 
magnetic tape DLPs that require data to be sent, to 
determine the length of the erasure. 


Tag Control 
This three-bit field controls the setting and transfer of 
tags during I/O operations. 


Word-Oriented Transfer 
When this one-bit field is TRUE, the MLIP interprets the 
MLIP Current I/0 Length (Word 11) in units of words, as 
opposed to characters. 


Memory Direction 
When this one-bit field is TRUE and the Input field of the 
MLIP Control Word is TRUE, then the MLIP transfers the 
received data to memory locations of descending order. 


Continue Count at End of Length 
When this one-bit field is TRUE, the MLIP allows the DLP 
to transfer more data than the originally specified I/0 
length (allowing the MLIP Current I/O Length (Word 11) to 
be decremented past 0), but does not store the excess data 
in memory. This field is set to TRUE when the _ software 
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requires information about the actual length of a block 
read from a variable-record-length device such as tape. 


Ignore Count Error 


When this one-bit field is TRUE, the MLIP will not report 
a Count Error, even if the MLIP Current I/O Length (Word 
11) is not 0 when the I/O has finished (see "MLIP State 
and Result" below). This field is set to TRUE for some 
I/Os to fixed-record-length devices and for some tape read 
operations (especially when the Continue Count at End of 
Length is TRUE). Ignore Count Error is specifically set 
to FALSE for I/Os for which the length of the data 
transfer nust be exact (for example, for disk, Network 
Support Processor (NSP), and tape write operations). 


Don't Count 


When this one-bit field is TRUE, the MLIP will not 
increment or decrement the command or unit queue's Active 
Count for this I/O. This feature is used only when 
initiating a Cancel operation (used only for DLPs that do 
not support a Discontinue operation), because the Cancel 
does not finish normally. 


Ignore Suspend All Queues 


The MLIP ias a bit (MLIP Suspend All Queues field) set to 
unconditionally suspend the command or unit queue when the 
I/C completes. However, if the Ignore Suspend All Queues 
field is TRUE, the MLIP will not suspend the command or 
unit queue when the I/0 completes. This feature is used 
only when initiating Error I0OCBs (see "“MLIP Error 
Handling"). 


Immediate 


Disk 


When this one-bit field is TRUE, the MLIP will ignore the 
value of the command or unit queue's Active Count and 
Suspended fields when considering initiating the IOCB. 
This field is usually set for MLIP operations (see the 
"MLIP" section), for peripheral status operations (see the 
“Peripheral Status" section), and for retry I/Os. 


Seek Optilization 
When this one-bit field is TRUE, the MLIP is allowed to 
reorder «he IOCB with respect to other IOCBs in the unit 
queue. Disk seek optimization is available only on A 3K 
and A 10 systems. 
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Simple Path Selection 
When this one-bit field is TRUE, the MLIP uses the path 
specified in the unit queve. The Path Table Pointer (Word 
9) of the unit queue specifies the path (see "Unit 
Queue"). Simple path selection is available only on A 3K 
and A 10 systems. 


DLP Address Word 

Word 1 contains several fields used by the MLIP to address a 
DLP. For A 3, A 9, B 5900, and B 6900 systems, this word 
contains an MLI port number, a Line Expansion Module (LEM) port 
number , and a DLP address within the base (see "Path 
Specification"). The A 3K and A 10 systems also use the above 
fields and have three additional fields: an MLIP processor ID, 
a Host Return field, and a DLP index. 


Command or Unit Queue Header Pointer 
Word 2 contains a reference to the command queue header for the 
command queue, or the unit queue header for the unit queue, in 
which the IOCB is to be queued. 


IOCB Self Pointer 
Word 3 contains a reference to the IOCB itself. 


DLP I/O Command Pointer 
Word 4 contains a reference to the memory area containing the 
command to be sent to the DLP. 


DLP I/O Result Pointer 
Word 5 contains a reference to the memory area in which the DLP 
result is to be stored. 


DLP Command/Result Lengths 
Word 6 contains the length of the DLP command to be sent and 
the length of the expected DLP result. For A 3K and A 10 
systems it also contains a Disk Address field. If the IOCB 
indicates that disk seek optimization is to be performed, this 
field contains the 16 most significant bits of the disk address 
at which the data transfer begins. 


Result Mask 
Word 7 contains a mask indicating which DLP results are not to 
be considered exceptions for the purpose of reporting DLP 
errors in the MLIP result (see "MLIP State and Result" below). 


Result Queue Head Pointer 
Word 8 contains a reference to the result queue head for the 
result queue into which this IOCB is to be queued upon 
completion. 


Next 


MLIP 


MLIP 


MLIP 
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IOCB Link 

Word 9 contains a link to the next IOCB in the command queue or 
result queue for A 3, A 9, B 5900, and B 6900 systems. The 
MLIP updates this link as the I/O is being processed. For A 3K 
and A 10 systems this word contains a link to the next IOCB in 
the IOCB queue, unit queue, or result queue. The MCP updates 
the link when queuing IOCBs in the IOCB queue. 


Current Data Area Pointer 

Word 10 contains a reference to the data area for the data to 
be transferred. It is initialized using the buffer descriptor, 
offset, and length passed to PHYSICALIO by the I/O requestor, 
and is updated by the MLIP as data is transferred. 


Current I/O Length 

Word 11 contains the length of the data area remaining for data 
transfer. It is initialized to the I/O length passed to 
PHYSICALIO by the I/O requestor and is updated by the MLIP as 
data is transferred. 


State and Result 

Word 12 is assigned by the MLIP to report the result 
information for the I/O performed. The following types of 
exceptions are reported: 


Exception 
This one-bit field is set when any other exception fields 
are set. 


Attention 
This one-bit field is set in the MLIP Control Word (Word 
9) in the IOCB. 


DLP Error 
This one-bit field is set when the result of masking the 
first 48 bits of the DLP result with the Result Mask (Word 
7) in the IOCB is not O. 


MLIP/MLI Error 
This one-bit field is set if any of the following one-bit 
exception fields for the MLIP State and Result word are 
set: 


Memory Protect 

Count, Error 

Improper IDJCB Word (for example, incorrect tag) 
Invalid MLIP Control Field 

MLI Vertical Parity Error 

MLI Longitidinal Parity Word Error 

Unexpected DLP Status (MLI protocol error) 
Nonpresent DLP 
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DLP Busy 
MLI Time Out 
Invalid MLIP Command 


MLIP/Hardware Error 
This one-bit field is set when an error occurs that must 
be reported through an Error I0OCB (see "MLIP Error 
Handling"). 


Completed After Queue Suspended 
This one-bit field is set if the I/O finished when the 
Suspended field in the Queue Control Word of the command 
queue header is TRUE (see "Command Queue"). 


MLIP Not Available 
This one-bit field is available only on A 3K and A 10 
systems and is set if the DLP Address Word (Word 1) of the 
IOCB references an MLIP processor ID that is not 
available. 


I/O Start Time 
The MLIP stores the time of day into Word 13 when the MLIP 
initiates the I/0. 


I/O Finish Time 
The MLIP stores the time of day into Word 14 when the I/O is 
finished. 


Before passing the IOCB to the MLIP, PHYSICALIO ensures that the IOCB 
contains all of the information required for the I/O operation. Some 
information is not required for some types of I/0 operations. For 
example, information pertaining to DLPs is not required for operations 
directed to the MLIP itself, and information pertaining to data buffers 
and lengths is not required for operations that do not involve data 
transfer. Some words in the IOCB are changed as the IOCB is queued, 
initiated, processed, and finished. These changes are described as the 
discussion proceeds through the I/O process. 


see also 
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CUIO OPERATOR 


The CUIO operator is used in A 3, A 9, B 5900, and B 6900 systems and is 
executed by the MCP to pass the address of an IOCB to the MLIP for 
initiation. The processor executing the CUIO operator verifies that its 
parameter is the addr2ss of an IOCB by checking the IOCB Mark field in 
the MLIP Control Word (Word 0). If the mark is not correct, an Invalid 
Operand interrupt is generated; if it is correct, the address is passed 
to the MLIP, and the operator completes when the MLIP indicates that it 
has received the addres3. 


The MLIP also verifies the IOCB Mark field. If the mark is not correct, 
an Error IOCB is completed (see "MLIP Error Handling"). If the mark is 
correct, the MLIP queues the referenced IOCB into the command queue 
specified by the Command Queve Header Pointer (Word 2) and determines 
whether or not to initiate the first I/O in that command queue. The I/O 
initiation process involves some changes to the IOCB (described in "IOCB 
Queue") and may require communication with the UIO subsystem (described 
in the "MLIP/UIO Interface" section). 


See also 
MEIP Error: Handi n ese vex ea a cee 32 oo a a ee oe a OE Ee a A Me a tee BS 
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LOCB QUEUE 


The IOCB queue is used by PHYSICALIO in the A 3K and A110 systems to 
send IOCBs to the MLIPs. To assure that I/Os are initiated in the 
correct order for single-user devices such as tape drives and printers, 
oniy one IOCB queue should be created per partition. Each MLIP's I/0 
table contains a pointer to the IOCB queue in the IOCB Queue Head 
Pointer (Word 1). 


The IOCB queue is composed of the three words shown in Table 2 and 
described below. 


Table 2. IOCB Queue 


Word 0 | IOCB Queve Control Word | 
a a a a | 
Word 1 | IOCB Queue Head | 
a a aaa a | 
Word 2 | IOCB Queue Tail | 


IOCB Queue Control Word 
Word O contains the IOCB Queue Mark 4'10Cl' and a lock bit. 
The lock bit is used by PHYSICALIO and the MLIP to synchronize 
access to the IOCB queue. 


IOCB Queue Head 
Word 1 contains a reference to the first IOCB in the IOCB 
queue. 


IOCB Queue Tail 
Word 2 contains a reference to the last IOCB in the IOCB queue. 
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COMMAND QUEUE 


A command queue is used in A 3, A 9, B 5900, and B 6900 systems and is a 
linked list of IOCBs that are to be initiated, usually to the same unit. 
A command queue is controlled by a data structure called a command queue 


header, 


Which iS comsosed of the five words shown in Table 3 and 


described below. 


Table 3. Command Queue 


Word 0 | Queue Control Word | 
wis (eee | 
oh Meee | 
eee. Fee i ee 
te eee | 


Queue Control Word 


Word 0O contains several fields that provide parameter 
information es:ablished by the MCP and queue status information 
maintained by the MLIP. 


Command Queue Header Mark 
This 16-bit field contains the code 4'10CC', which marks 
the word as the first word of a command queue header. 


Inactive Count 
This eigh:-bit field contains the number of IOCBs that are 
currently queued but have not been initiated. 


Active Count 
This eigh:-bit field contains the number of IOCBs that 
have been initiated out of the queue and are still in 
progress. 


Active Limit 

This eigh:-bit field is initialized by the MCP to the 
maximum number of IOCBs from this queue that may be 
Simultaneously in progress. The MLIP will not initiate 
any IOCBs from the queue if the Active Count is greater 
than or equal to the Active Limit, unless the IOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE (see "IOCB"). 
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Suspended 

This one-bit field is set to TRUE under the following 

conditions: 

as When an IOCB initiated out of the queue completes 
with the Exception field in the MLIP State and Result 
(Word 12) set to TRUE 

2% When an IOCB initiated out of the queue is completed 
while the MLIP Suspend All Queues field is TRUE and 
the Ignore Suspend All Queues field in the I0OCB‘'s 
MLIP Control Word (Word 0) is FALSE 

3% When the MCP requests the MLIP to deactivate the 


queue (see "MLIP") 


If the command queue's Suspended field is TRUE, the MLIP 
will initiate an IOCB out of the queue only if the IOCB 
being considered for initiation has the Immediate field in 
the MLIP Control Word (Word 0) set to TRUE. 


Waiting 
This one-bit field is set to TRUE by the MLIP when the 
command queue is linked into a horizontal queue (see 
"Horizontal Queue"). 


Horizontal Queue Present 
This one-bit field is set to TRUE by the MCP to indicate 
that the MLIP can link this queue into the horizontal 
queue specified in the Horizontal Queue Head Pointer field 
(see below) when necessary. 


Head IOCB Link 
Word 1 contains a reference to the first (inactive) IOCB in the 
command queue. It is updated whenever an IOCB is unlinked from 
the queue and whenever a new IOCB is inserted at the head of 
the queue because the Queue at Head field in the MLIP Control 
Word (Word 0) of the IOCB was TRUE. 


Tail IOCB Link 
Word 2 contains a reference to the last (inactive) IOCB in the 
command queue. It is updated whenever a new IOCB is linked at 
the end of the queue and whenever the last IOCB is initiated 
out of the queue. 


Horizontal Queue Head Pointer 
Word 3 is initialized by the MCP and contains a reference to 
the head of the horizontal queue into which this command queue 
is to be linked if necessary (see “Horizontal Queue"). 
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Horizontal Queue Linx 
Word 4 is used oy the MLIP to link the command queue into a 
horizontal queu> when necessary (see "Horizontal Queue"). 


For most devices, PHYSICALIO allocates one command queue per unit per 
path to that unit. For Operator Display Terminals (ODTs), there are two 
command queues per unit: one for writes and one for reads and test/wait 
for transmit operations. For Network Support Processors (NSPs), three 
command queues for each NSP are allocated (see the "Data Communications" 
section). 


When an I/O is linked i1to a command queue, the MLIP updates the 
Inactive Count field of cthe Queue Control Word (Word 0) to indicate that 
another IOCB has been queued. If the IOCB was queued at the head of the 
command queue, the Head IOCB Link (Word 1) in the command queue header 
and the Next IOCB Link (Word 9) of the IOCB following the new IOCB are 
updated: if the IOCB was queued at the tail of the command queue, the 
Tail IOCB Link (Wcrd 2) of the command queue header and the Next IOCB 
Link (Word 9) of the IOUB preceding the new IOCB are updated. Figure 5 
shows three IOCBs linked into command queue header "A". 
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Command Queue Header "A" 


| 
| | 
| | 
| | 
| | HQ Link | | 
| a a aa | | 
| | 
| (eee Fh pre rn HK meen re + | 
| | > ul 
| IOCB 1 | IOCB 2 | IOCB 3 | | 
ers oeeeee || [eas Pa |----------- bot 
Pe ee ee ee) EF deed besa 

| ----------- J ogof  [----+------ | |b [-es-------- || 

| CQ Header ---| | | CQ Header ---| | | CQ Header ---~| 

Reece Jo | [peeeee-=-~- ee ee | 

| | | | | | | | 

| --~-------- Po f [pe eee ee =- ee ee Cees | 

| Next Link ----- | | Next Link ----- | | Next=NULL | 


CQ = Command queue 
= Horizontal queue 


wm 
O 
| 


Figure 5. Multiple IOCBs Linked to a Command Queue 


The command queue header links are static throughout the processing of 
the IOCB and are not shown in Subsequent figures. 


The MLIP begins processing a particular command queve under any of the 
following circumstances: 


Ls When PHYSICALIO initiates an IOCB to that queue. 
os When an I/O operation for an IOCB in that queue is complete 
(for example, when an activate queue MLIP operation, simply by 


ending, causes that command queue to be processed by the MLIP). 


ce When the command queue is reached by following the links in a 
horizontal queue (see "Horizontal Queue"). 


46 


PHYSICAL I/0 OVERVIEW 
Whenever the MLIP is processing a particular command queue, it attempts 
to initiate as many IOCBs as possible from that queve. The number of 


IOCBs that can be initiated depends on factors such as whether or not 


- The command queue's Active Count is less than the command queue's 
Active Limit. 


~ The Suspended field is TRUE. 
- The IOCB's Immediate field is TRUE. 


- The command queue is already queued in a horizontal queue waiting 
for the DLP (see "Horizontal Queue"). 


When an IOCB is initiated, the IOCB's Next IOCB Link (Word 9) is set to 
1 and the IOCB is unlinked from the command queue, as shown in Figure 6. 


Command Queue Header "A" 


| 

| 

| 

| HQ Link | | 

| ----------------------- | | 

| 

SS eeoer Sas | | 

| | 

IOCB 1 | IOCB 2 IOCB 3 | 

| ----------- ee | | ----------- ‘a 

| eo | => <==] 
[Sane eae | pS eS | | [SHRP Sees | 
| CQ Header | | CQ Header | | | CQ Header | 
| Seaeeee===2 | [Reser eee | | [paS SSS eae | 
| | | | | | | 
[SSS | Soe See ye oee | | [SSeS na Saas | 
| Next=1 | | Next Link ~---- | | Next=NULL | 


CQ = Command queue 
Horizontal queue 


oq 
© 
UW 


Figure 6. Init:ated IOCB Unlinked from a Command Queue 


47 


PHYSICALIO/MLIP Interface 


At the time the I/O is initiated, the MLIP sets the I/O Start Time (Word 
13) of the IOCB to the time of day. 


For I/O operations that involve data transfer, the data is transferred 
in bursts when the DLP indicates that it is ready to receive or transmit 
data (see the "MLIP/UIO Interface" section). As data is sent to or 
received from the DLP, the MLIP adjusts the MLIP Current Data Area 
Pointer (Word 10) and the MLIP Current I/O Length (Word 11) of the IOCB 
to correspond to the location and amount of data left to be transmitted. 


see also 
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UNIT QUEUE 


A unit queue is used in A 3K and A 10 systems and is a linked list of 


IOCBs 


that are to be initiated, usually to the same unit. A unit queue 


is controlled by a data Structure called a unit queue header, which is 
composed of the 11 words shown in Table 4 and described below. 


Table 4. Unit Queue 


Word 0: | Queue Control Word | 
wid. Mock OO | 
mee, Gee | 
wee ee eee 
Ale ieee | 
meas eee : 
[4 ha : 
is 1a : 
was. (oe | 
oak. ee : 
eee Soh oe coe 


Queue Control Word 


Word QO contains fields that provide parameter information 
established by the MCP and queue status information maintained 
by the MLIP. 


Unit Queue Header Mark 
This lo-bi: field contains the code 4'10CC', which marks 
the word as the first word of a unit queue header. 


Inactive Count 
This eight-bit field contains the number of IOCBs that are 
currently queued but have not been initiated. 


Active Count 
This eight--bit field contains the number of IOCBs_ that 
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have been initiated out of the queuve and are still in 
progress. 


Active Limit 


This eight-bit field is initialized by the MCP to the 
maximum number of IOCBs from this queuve that can be 
Simultaneously in progress. The MLIP will not initiate 
any IOCBs from the queuve if the Active Count is greater 
than or equal to the Active Limit, unless the IOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE (see “IOCB"). 


Suspended 


This one-bit field is set to TRUE under the following 
conditions: 


Ls When an IOCB initiated out of the queue is completed 
with the Exception field in the MLIP State and Result 
(Word 12) set to TRUE 


2% When an IOCB initiated out of the queve is completed 
while the MLIP Suspend All Queues field is TRUE and 
the Ignore Suspend All Queues field in the IOCB's 
MLIP Control Word (Word 0) is FALSE 


cin When the MCP requests the MLIP to deactivate the 
queue (see the "MLIP" section) 


If the unit queue's Suspended field is TRUE, the MLIP will 
initiate an I0OCB out of the queue only if the IOCB being 
considered for initiation has the Immediate field in the 
MLIP Control Word (Word 0) set to TRUE. 


Waiting 


This one-bit field is set to TRUE by the MLIP when the 
unit queve is linked into a horizontal queue (see 
"Horizontal Queue"). 


Horizontal Queue Present 


Path 


This one-bit field is set to TRUE by the MCP to indicate 
that the MLIP can link this queue into the horizontal 
queue specified by the Horizontal Queue Head Pointer field 
(see below) when necessary. 


Selected 

This one-bit field tells whether or not the MLIP has 
executed the Path Selection algorithm for the top IOCB in 
the unit queue. 
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Connection in Frogress 
If this one-bit field is set, an MLIP has initiated a Poll 
Test to the DLP specified by the Data Link Processor 
Address Wcrd (DLPAW) of the top IOCB in the unit queue. 


Waiting in MLIF Queue 
If this one-bit field is set, the unit queve is currently 
dynamically linked in an MLIP queue. 


Lock Bit 
This one-trit field is used by the MLIPS to synchronize 
access to the unit queue. 


Head IOCB Link 
Word 1 contains a reference to the first (inactive) IOCB in the 
unit queue. It is updated whenever an IOCB is unlinked from 
the queue and whenever a new IOCB is inserted at the head of 
the queue because the Queue at Head field in the MLIP Control 
Word (Word 0) cf the IOCB was TRUE. 


Tail IOCB Link 
Word 2 contains a reference to the last (inactive) IOCB in the 
unit queue. It is updated whenever a new IOCB is linked at the 
end of the queue and whenever the last IOCB is initiated out of 
the queue. 


Horizontal Queue Head Pointer 
Word 3 is initialized by the MCP and contains a reference to 
the head of the horizontal queue into which this unit queue is 
to be linked if necessary (see "Horizontal Queues"). 


Dynamic Unit Queue Link 
Word 4 is used by the MLIP to dynamically link unit queues in 
horizontal queues and MLIP queues. 


Last IOCB Initiated 
Word 5 references the last non-MLIP command IOCB initiated from 
the unit queue. 


Spare 
word 6 is reserved for future expansion. 


I/O Optimization Word l 
Word 7 contains information that is used to optimize the 
throughput of disk I/Os. 


Physical Integrity Check 
This one-bit field determines whether the MLIP guarantees 
that overlapping I/Os are not reordered with respect to 
one another. 
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Maximum IOCBs to Examine 
This six-bit field determines the maximum number of IOCBs 
that are examined by the Disk Seek Optimization algorithm. 


Bypass Limit 
This four-bit field contains the maximum number of times 
that the top IOCB can be bypassed in favor of another IOCB 
in the unit gueue at IOCB initiation time. 


Bypass Count 
This four-bit field contains the number of times that the 
top IOCB has been passed over in favor of another IOCB in 
the unit queue at IOCB initiation time. 


Disk Address 
This 16-bit field contains the value from the Disk Address 
field in the DLP Command/Result Lengths (Word 6) in the 
IOCB selected as the best IOCB by the Disk Seek 
Optimization algorithm. 


I/O Optimization Word 2 
Word 8 contains information that iS used to optimize the 
throughput of disk I/Os. If the Physical Integrity Check field 
of I/O Optimization Word 1 is set, PHYSICALIO must initialize 
the Cylinder Size and Minimum Difference fields. 


Cylinder Size 
This 28-bit field contains the size of a disk cylinder in 
bytes. 


Minimum Difference 
This 20-bit field contains the information to determine if 
I/Os overlap. 


Path Table Pointer 
Word 9 contains the address of the DLP for simple path 
selection. 


Unit-Related Path Information 
Word 10 contains unit-related path information and the 
following field. 


Unit DLP Mask 
This field specifies the DLPs through which there is a 
ready physical path to the unit. 


PHYSICALIO allocates one unit queue per unit, regardless of the number 
of paths to the unit. The name "unit queue" implies that all I/Os for 
one unit are sent to a single queue. 
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When an I/O is linked into a unit queue, the MLIP updates the Inactive 
Count field of the Queve Control Word (Word 0) to indicate that another 
IOCB has been queued. If the IOCB was queued at the head of the unit 
queue, the Head IOCB Link (Word 1) in the unit queue header and the Next 
IOCB Link (Word 9) of the IOCB following the new IOCB are updated; if 
the IOCB was queued at the tail of the unit queue, the Tail IOCB Link 
(Word 2) of the unit queue header and the Next IOCB Link (Word 9) of the 
IOCB preceding the new IOCB are updated. Figure 7 shows three IOCBs 
linked into unit queue header "A": 


Unit Queue Header "A" 


(------- $(------------------- + <------------------- + 

| | | 

IOCB 1 | IOCB 2 | IOCB 3 | 

Sawer eases ae [ieee err | | [Sarge | | 

==, LE al ee lk, sel Ea )e= 

| Seeenmminnieees (hed [ae re | pee eee ia 

| UQ Header ---| | | UQ Header ---| | | UQ Header ---| 
[aaa eaa r= | | SaaS SS | | eee os eer | 
| | | | | | | | 
|----------- en eee | | [peeeeae--~ | 
| Next Link ---~-- | | Next Link ----- | | Next=NULL | 


HQ = Horizontal queue 
Unit queue 


a 
Oo 
H 


Figure 7. Multiple IOCBs linked to a Unit Queue 
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The unit queue header links are static throughout the processing of the 
IOCB and are not shown in subsequent figures. 


The MLIP begins processing a particular unit queue under any of the 
following circumstances: 


AIS When PHYSICALIO initiates an IOCB to that queue 


eae When an I/O operation for an IOCB in that queue is complete 
(for example, when an Activate Queue MLIP operation, simply by 
ending, causes that unit queue to be processed by the MLIP) 


3s When the unit queue is reached by following the links in a 
horizontal queue (see "Horizontal Queue") 


Whenever the MLIP is processing a particular unit queue, it attempts to 
initiate as many IOCBs as possible from that queue. The number that can 
be initiated depends on factors such as whether or not the unit queue's 
Active Count is less than the unit queue's Active Limit, whether or not 
the Suspended field is TRUE, whether or not the IOCB's Immediate field 
is TRUE, and whether or not the unit queue is already queued ina 
horizontal queue waiting for the DLP (see "Horizontal Queue"). 
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When an IOCB is initiated, the IOCB's Next IOCB Link (Word 9) is set to 


lL and the IOCB is unlinked from the unit queue, as shown in Figure 8. 


Unit Queue Header "A" 


IOCB 1 | IOCB 2 IOCB 3 
eee | | [PSS eases | (SaaS | 
| | pao | hee (‘<= 
aa a ee | [SSsarSrases | | (pS Ses SsneSs | 
| UQ Header | | UQ Header | | | UQ Header | 
ante am | [SRS egoas | | ass SS | 
| | | | | | | 
| -----=----- | |----------- ee eee | 
| Next=1 | | Next Link ----- | | Next=NULL | 


= Horizontal queue 
= Unit queue 


aw 
DO 
to 


Figure 8. Initiated IOCB Unlinked from a Unit Queue 


At the time the I/O is initiated, the MLIP sets the I/O Start Time (Word 
13) of the IOCB to the time of day. 
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For I/O operations that involve data transfer, the data is transferred 
in bursts when the DLP indicates that it is ready to receive or transmit 
data (see the "MLIP/UIO Interface"section). As data is sent to or 
received from the DLP, the MLIP adjusts the MLIP Current Data Area 
Pointer and the MLIP Current I/O Length (Words 10 and 11) of the IOCB to 
correspond to the location and amount of data left to be transmitted. 


See also : 
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The MLIP I/O table is used by the MLIP in the A 3K and A110. systems. 
The MCP sets up an MLIP I/O Table for each MLIP in the partition. Once 
the table has been set up, the MCP is no 
any word in the table except through an MLIP I/O operation. 


The MLIP I/O table, shown in Table 5 bel 
the MLIP queue, destination sets, and 
Descriptions of these words and fields are given below. 


pointer, 


Word 
Word 
Word 
Word 
Word 
Word 
Word 


Word 


Word 


Table 5. MLIP I 


MLIP Scratch Area Word O 


t allowed to 


update 


or access 


ow, contains an IOCB queue head 
a scratch area. 


/O Table 


| ---------- wanna nnn nnn nnn nnn nnn nnn enna nnn | 


L672: "|| 


MLIP Scratch Area Word 9 


MLIP I/O Table Cont:rol Word 
Word O consist; of the MLIP 
containing the code 4'10CO'. 


IOCB 


Queue Head Pointer 


Word 


1 contains a pointer 


initializes the IOCB queue 
altered by the MLIP or the MCP. 


I/O table control 


to the IOCB 
head pointer, 


queue. 
which 


mark field 


The MCP 
cannot be 


MLIP 


MLIP 
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Queue Control Word 
Word 2 consists of a MLIP queue mark field, an undefined area, 
and a lock bit. 


MLIP Queue Mark 
The MLIP Queue Mark field contains the code 4'10C2'. 


Lock Bit 
MLIPs use the lock bit to synchronize access to the MLIP 
queue. 


Queue Head Unit Queue Link Data Descriptor 
Word 3 contains the pointer to the first unit queue in the MLIP 
queue. PHYSICALIO initializes this word to 0. 


Queue Tail Unit Queue Link Data Descriptor 
Word 4 contains the pointer to the last unit queue in the MLIP 
queue. PHYSICALIO initializes this word to 0Q. 


EMP Destination Set 


MLIP 


MLIP 


Word 5 contains the destination set of EMPs that are signaled 
for I/O Finish. The EMP destination set is a bit mask where 
bit 1 corresponds to EMP #1, bit 2 corresponds to EMP #2, and 
sO on. The MCP sets a bit for each running EMP in the 
partition. If the partition configuration changes, the MCP 
updates the word by using an MLIP command. 


Destination Set 

Word 6 contains the destination set of MLIPs. An MLIP can 
communicate only to MLIPs specified in this word. The MLIP 
destination set is a bit mask where bit 1 corresponds to MLIP 
#1, bit 2 corresponds to MLIP #2, and so on. The MCP sets a 
bit for each running MLIP in the partition. If the partition 
configuration changes, the MCP updates the word by uSing the 
MLIP command. 


Scratch Area Word 0 through Word 9 

The MLIP uses this aS a scratch area that consists of 10 words 
(Word O through Word 9). The MCP initializes the scratch area 
to: 0. 
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HORIZONTAL QUEUE 


A horizontal queue is a mechanism for queuing command queues or. unit 
queues when the DLP path to the unit is busy. The A 3, A 9, B 5900, and 
B 6900 systems use the command queue, and the A 3K and A 10 systems’ use 
the unit queue, to initiate the MLIP. The term "command/unit queue" is 
used to refer to the queue for its respective computer system. 


During system initialization, PHYSICALIO builds a horizontal queue array 
containing a one-word horizontal queue header for each of several 
horizontal queues (Word O of the array contains a Queue Length field and 
the code 4'10CE' as a Horizontal Queue Mark). In general, PHYSICALIO 
assigns a horizontal queue header for each DLP that can accept multiple 
I/O requests but might be momentarily unable to accept a command because 
it is actively processing a previous command. 


When the MLIP attempts =o initiate an I/O to a DLP that is busy, the 
MLIP checks the Horizon*:al Queue Present field in the Queue Control Word 
(Word 0) in the command/unit queue header to determine whether or not 
this command/unit queue is eligible to be queued into a horizontal 
queue. If so, the MLIP queues the command/unit queue in the horizontal 
queue specified by the Horizontal Queve Head Pointer (Word 3) in the 
command/unit queue header. If this command/unit queue is the first in 
the horizontal queue, =he Horizontal Queue Head is set to point to this 
command/unit queue. If it is not the first (that is, if there is 
already at least one command/unit queue in the same horizontal queue), 
this command/unit queue is linked to the tail of the horizontal queue. 
In A 3, A 9, B 5900, and B 6900 systems, the Horizontal Queue Link (Word 
4) in the command queue header of the command queve (previously at the 
tail of the horizontal queue) is set to point to this command queue. In 
A 3K and A 10 systems, =the Dynamic Unit Queue Link (Word 4) in the unit 
queue header of the uni: queue is set to point to this unit queue. 


In order to support uni: queves, the MLIPS must share the horizontal 
queue array. This sharing is done by having each MLIP lock the entire 
horizontal queue array prior to queuing or unqueuing unit queues. Word 
O of the Horizontal Queue Array is used as the lock word. 
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Figure 9 shows two command queues linked into the same horizontal queue. 


Horizontal Queue Array 


| Header | | | HQ Head! | | 
|Word | | | | | | 


| Command Queue Header "A" Command Queue Header "B" 


——————————> 


| HQ Head Pointer -->+<-- HQ Head Pointer | 


|-----~--- ~-----=------- | | ----------------------- | 


HQ = Horizontal queue 


Figure 9. Multiple Command Queues Linked to a Horizontal Queue Array 


When the MLIP finishes processing a command/unit queue (that is, when it 
cannot initiate any more commands from that command/unit queue), it 
checks the horizontal queue referenced by the command/unit queue header 
to see if other command/unit queues are waiting. If so, the MLIP 
unlinks and begins processing the first command/unit queue in the 
horizontal queue. In this fashion, the MLIP traverses the entire 
horizontal queue. 


60 


PHYSICAL I/O OVERVIEW 


RESULT QUEUE 


Result queues are lists of completed IOCBs. During system 
initialization, PHYSICALIO builds a result queue array for. each 
processor in A 3, A 9, B 5900, and B 6900 systems. In A 3K and A 10 


systems, only one result queue array is initialized. A result queue 
array contains a header word (which includes a Queue Length field and 
the code 4'10CF' as the Result Queue Mark) and a one-word Result Queue 
Head for each of several result queues. The exact number of result 
queues is determined by the number of classes of results that are to be 
queued separately. Typically, PHYSICALIO establishes seven result 
queues, one for each of he following result classes: 


Ds Normal I/Os 

2 Internal PHYSICALIO ("kernel") I/Os 
3. Peripheral status I/Os 

4. Error IOCB I/Os 

am Datacomm I/Os 

6. Intersystem con:zrol I/Os 

rs Disk and pack I/Os 


Before passing an IOCB to the MLIP, the MCP must indicate, in the Result 
Queue Head Pointer (Word 8) of the IOCB, which result queve the IOCB is 
to be queued into on comsdletion. When the operation is complete, the 
MLIP sets the 1/0 Finisi Time (Word 14) of the IOCB to the time of day, 
stores its MLIP result iito the MLIP State and Result (Word 12), and 
stores the DLP result in the location specified by the DLP I/O Result 
Pointer (Word 5). The MLUIP then links the IOCB at the head of the 
result queue specified (that is, the result queue is last-in, first-out) 
and decides whether or not to cause an I/O Finish interrupt (see "I/O 
Finish Interrupt"). 


Because several MLIPsS can update the same result queue, the Next IOCB 
Link (Word 9) cf the first IOCB is checked before the result queue is 
updated. The MCP checks the Next IOCB Link (Word 9) for its value. ret 
the value is 1, the IOCB is not processed. 


In the situation depictei by Figure 10, IOCBs 1 and 2 of command queue 
"A" have completed, IOCB 1 first; both are linked into result queue "L." 
Command queue header "A" is queued in horizontal queue "Z," waiting for 
the DLP to beccme available so that IOCB 3 can be initiated. When 
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IOCB 3 completes, it will be linked into result queve "M." In A 3K and 


A 10 systems, a unit queue can be used in place of the command queue in 
this example. 


Command Queue Header "A" 


| RQ Head a 
| -------------- 


| Next=NULL | === Next Link | | Next=NULL | 
i eso a aaa | bay Sea eee | Notes a ce aa | 
| | | | | | 
ag ac eo | [Sones ateaeSSs= | (SSS Sane Sa | 
[Se Sao e SS | 
| 
Peaee Sse e Sea t= a a a ed | 
| Header | IRQ Head |RQ Head | | | | | 
[Word | pro |"M" | | | | | 


Result Queue Array 


CQ = Command queue 
HQ = Horizontal queue 
Result queue 


w 
Ce) 
uN 


Figure 10. Multiple IOCBs Linked to a Result Queue Array 
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I/O FINISH INTERRUPT 


When the MLIP has finished processing an IOCB and the IOCB has_ been 
linked into the appropriate result queue, the MLIP must decide whether 
or not to cause an I/O Finish interrupt to notify the processor. The 
MLIP will cause an <</O Finish interrupt for any one of the following 
conditions: 


te The MCP has requested an interrupt by setting the Cause I/0 
Finish Interrupt field in the MLIP Control Word (Word 0) of the 
completing IOCB. 


2% The Exception field in the MLIP State and Result (Word 12) of 
the completing IOCB is TRUE. 


Die The command/un:t queue of the finishing IOCB is empty. 
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MLIP ERROR HANDLING 


In addition to IOCBs that the MCP allocates to perform I/Os, a_ small 
number of IOCBS are allocated to provide the MLIP with a mechanism to 
report errors that are not relevant to the IOCB currently in progress, 
or for which there is too much information to be reported in the IOCB. 


These "Error IOCBs" are initiated during system initialization, but are 
not completed until they are needed to report one of the following 
errors: 


- An invalid queue structure (for example, bad queue mark). 
- An invalid queue reference. 


- A bad descriptor link received from a DLP (see the "MLIP/UIO 
Interface" section). 


- A memory error detected by the MLIP. 


Error IOCBs have their own command/unit queue and result queue. Because 
it is important that the Error IOCB command/unit queue not be suspended, 
the MCP and the MLIP take special precautions when handling Error IOCBs. 


In order that the Exception field does not get set to TRUE, the 
following must happen: the MCP must issue all Error IOCBs with the 
Attention field set to FALSE; the MLIP must not set the DLP Error, 
MLIP/MLI Error, MLIP/Hardware Error, or Completed After Queue Suspended 
fields to TRUE. In order that the queue does not get suspended because 
the MLIP Suspend All Queues field is TRUE, the MCP must issue all Error 
IOCBs with the Ignore Suspend All Queues field set to TRUE. 


The MCP issues all Error IOCBs with the Cause I/O Finish interrupt field 
set to TRUE. This action is required because the MLIP is not permitted 
to set any exception fields, and there is no other way for an interrupt 
to be generated. 


See also 
POCB:. a ar 4. 4: ae et ec a BS Be es BO ee ce ee re, SS 
MGEPAULO: tnpertace.- 2° ts 2 St ae wh a Se le wk RES Oh SB Ce et oe) E 
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The Message-Level Interface Processor (MLIP) is a hardware module with 
the following purposes: 


- To accept I/O operations from the Master Control Program (MCP). 
- To queue the I/0 operations. 


- To route the I/0 operations to their destination Data Link 
Processors (DLPs). 


- To handle the Message-Level Interface (MLI) dialog with the DLP. 


- To return the result information to the MCP. 


Many of these functions are described in other sections of this manual, 
particularly in the "PHYSICALIO/MLIP Interface" section and the 
"MLIP/UIO Interface" section. 


MLIP COMMANDS 


The MLIP also performs operations itself. These functions are, for’ the 
most part, related to queue management and DLP configuration management 
and, with two exceptions, do not involve communication with the 
Universal I/O (UIO) subsystem. 


The MCP requests MLIP operations by setting the MLIP/DLP Command field 
in the MLIP Control Word (Word 0) of an Input/Output Control Block 
(IOCB) to TRUE (indicating MLIP command) and storing, in the first word 
pointed to by the DLP I/O Command Pointer (Word 4) in the IOCB, a code 
indicating a command. The following commands are available on all 
systems that support the MLIP I/O subsystem: 


This command indicates to the MLIP that the IOCB is to be used as an 
Error IOCB (see "MLIP Error Handling"). 
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Discontinue Error IOCB 


This command discontinue2s the currently active Error IOCB, if any. If 
there is no Error I93CB currently active. the MLIP will indicate that 
there is no Error IOCB to discontinue. This operation is used when 


changing software environments, such as when entering and exiting 
TAPEDUMP, to remove all outstanding Error IOCBs. 


Set the Suspend All Queues Flag 


This command sets the MLIP Suspend All Queues field, which suspends any 
active command/unit queues so that no more I/Os can be initiated (see 
"Command Queve" and "Unit Queue"). This command is issued by the MCP 
through the JIOFAUCET procedure. The purpose of the command is to 
prevent I/Os from being initiated during a memory dump. 


Reset the Suspend All Queues Flag 


This command resets the MLIP Suspend All Queues field. 


Activate Queue 


This command resets the Suspended field in the Queue Control Word (Word 
0) of the command/unit queue specified by the Command or Unit Queue 
Header Pointer (Word 2) in the IOCB, and to start processing the queue. 
This command is issued by the MCP to restart a command/unit queue after 
the exception condition that caused the queue to be suspended has _ been 
handled appropriately. 


Deactivate Queue 


This command sets the Sispended field in the Queue Control Word (Word 0) 
of the command/unit queue specified by the Command or Unit Queue Header 
Pointer (Word 2) in the IOCB. This command suspends the command/unit 
queue before TEST/WAIT operations and before operations that may alter 
the queue structure, such as BLASTUNIT, PATHRES, and UNITMOVER. 
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Return Queue 


This command returns the IOCBs queued in the command/unit queue 
specified by the Command or Unit Queue Header Pointer (Word 2). The 
MLIP returns the queue by copying the Head IOCB Link (Word 1) from _ the 
Command Queue Header into the first word pointed to by the DLP I/0 
Result Pointer (Word 5) and by setting the Head IOCB Link (Word 1), Tail 
IOCB Link (Word 2), and Inactive Count field of the Queue Control Word 
(Word 0) to 0. The MLIP will not remove the command/unit queue from the 
horizontal queue if it is currently linked. This command is issued by 
BLASTUNIT, for example, when it must alter the structure of the 
command/unit queue. 


Read IP Status 


This command returns one word of status information in the first word of 
the area pointed to by the DLP I/O Result Pointer (Word 5) in the IOCB. 
This status information includes the system type, the MLIP firmware 
revision, the Host Return field (see "Host Identification"), and a bit 
vector identifying the MLI ports that are present. This information is 
requested by the software during peripheral initialization. On A 3K and 
A 10 systems, the MLIP also returns information in bit 16 of the DLP I/O 
Result Pointer (Word 5) as to whether or not disk seek optimization has 
been implemented. 


Read DLP Status 


This command connects the MLIP to the DLP specified in the DLP Address 
Word (Word 1) of the IOCB and reads its status, which is returned in the 
MLIP State and Result (Word 12) of the IOCB. 


Clear DLP 


This command issues an "MLI selective clear" command to the DLP 
specified in the DLP Address Word (Word 1). This operation is used by 
IOFAUCET to clear TEST/WAIT operations when beginning a nonfatal dump 
and by BLASTUNIT when it must ensure that the DLP is in a known state. 
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General Clear 


This command issues an "MLIP master clear" command to all MLI_ ports. 
This command is issued by IOFAUCET when beginning a fatal dump, and by 
the soft Halt/Load procedure "FAKEHALTLOAD" to simulate the action of a 
Halt/Load. 


IP COMMANDS AVAILABLE ON A 3K AND A 10 SYSTEMS 


The following are addit:.onal MLIP commands available on the A 3K and 
A 10 systems. 


Return Active IOCB 


This command returns the active count of the unit queue and Last I0OCB 
Initiated (Word 5) of the unit queve to the first and second words 
pointed to by the DLP I,’/0 Result Pointer (Word 5) of the IOCB. This 
command is used by IODISASTER when handling hung DLPs. 


Set I/O Table EMPDS 


This command updates the EMP Destination Set (EMPDS) (Word 5) of the 
MLIP I/O table. The MCP uses this command after system initialization 
to update the destination set with all of the running E-Mode processors 
(EMPs). 


Set I/O Table MLIPDS 


This command updates the MLIP Destination Set (MLIPDS) (Word 6) of the 
MLIP I/O table. IOFAUCET uses this operator to update the MLIP I/0 
table with a mask of the running MLIPsS during a memory dump. 
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This command stores the second word pointed to by DLP I/O Command 
Pointer (Word 4) of the IOCB in the Path Table Pointer (Word 9) of the 
unit queue. The MCP uses thiS operation whenever a path has been 
selected for a unit. 
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Set Unit Queue I/O Optimization Word 2 


This command stores the second word pointed to by DLP I/O Command 
Pointer (Word 4) of the IOCB in the I/O Optimization Word 2 (Word 8) of 
the unit queue. This operation is used by the MCP to maintain data 
necessary for the MLIP to perform disk seek optimization. 


Decrement Unit Active Limit 


This command decrements the active limit field of the Queue Control Word 
(Word 0) of the unit queue. This operation is used by the MCP when 
maintenance tests are being run. 


Increment Unit Active Limit 


This command increments the active limit field of the Queue Control Word 
(Word 0) of the unit queue. This operation is used by the MCP when 
maintenance tests are being run. 


See also 
COmmManG..OUCUG: «fo se 2: de. Se Ee te Re ees te a ee? me ee 
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8 MLIP/UIO INTERFACE 


The Message-Level Interface Processor (MLIP) communicates with the 
Universal I/O (UIO) subsystem through the Message-Level Interface (MLI), 
a protocol-driven interface that allows the MLIP and the Data Link 
Processors (DLPs) to process independently between data transfer bursts. 
When the MLIP has an I/O operation to transfer to a particular DLP, it 
connects to the DLP and transfers the DLP command and a "descriptor 
link" to the DLP. The descriptor link contains two items: 


be The Host Return field, required for the return routing of 
information from the DLP to the MLIP (see "Host 
Identification"). 


2s A tag that uniquely identifies a particular I/O operation. 


After the DLP command and descriptor link have been transferred, the 
MLIP can disconnect and perform other operations. 


When a DLP is ready to transfer data, it reconnects to the MLIP and 
transfers the descriptor link for the I/O operation requiring the data 
transfer. The MLIP uses this descriptor link to find the appropriate 
Input/Output Control Block (IOCB) and reconstructs its state by 
accessing the intermediate results it previously stored in the IOCB. 
One or more blocks of data are then transferred, and the MLIP 
disconnects. 


When the DLP has finished the operation, it reconnects to the MLIP and 
transfers both the descriptor link and the DLP result descriptor for the 
completed operation. It then drops the connection, and the MLIP 
finishes processing the IOCB. 


See also 
Host. 1Ldentif ication: 2° @ sk 2) woe Be ae 8 OR mee tw SL ae 73 
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UIO SUBSYSTEM 


To determine the configuration of the I/O subsystem, PHYSICALIO must be 
able to uniquely identify every base, Data Link Processor (DLP), and 
unit in the subsystem. To initiate an I/0 to a specific unit, 
PHYSICALIO must be able to select and specify a path to that unit. 
Similarly, to return information to the system, the I/O subsystem must 
be able to uniquely identify each host. 


This section describes the rules and conventions that must be followed 
to establish a valid Universal I/O (UIO) subsystem configuration. 


HOST IDENTIFICATION 


From the UIO subsystem's point of view, a "host" is any system component 
that communicates with a base on a Message-Level Interface (MLI). A 
host can be an A 3, A 3K, A 9, A 10, 3B 5900, or B 6900 processor; a 
Network Support Processor (NSP); or a B 6900 maintenance processor. 


Each host connecting to a base has an identification number, called a 
Host Return field, that is used by the base to uniquely identify the 


host. The Host Return field must be in the range O through 7. The 
B 5900 and B 6900 processors generate Host Return fields that correspond 
to their processor IDs and, thus, are numbered from 1 through 4. The 


B 6900 maintenance processors use a Host Return field of 0, leaving the 
range 5 through 7 available for NSPs. 


For the A 3K and A 10 systems, the Host Return field corresponds to the 
MLIP number (1 through 7). 


A host connects to a base through a distribution card (DC), which is 
identified with a number that matches the Host Return field of the host 
it is connected to. There can be up to six DCS in one base, allowing up 
to six hosts to connect to the same base. Hosts that connect to DCs 
within the same base must have unique Host Return fields, but hosts that 
do not share bases need not have unique Host Return fields. A 
configuration that includes nonunique Host Return fields is illustrated 
in Figure 11, which shows two NSPs (both numbered 6) that do not connect 
to the same base. 
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| B 5900 Processor 1| | B 5900 Processor 2| 

| | | | 

(S=SSs===5>S=]=== > 5 | | 

| MLIP | | MLIP | 

| ---------~---------- | | ------------------- | 

|Port|Port|Port|Port | |Port|Port|Port|Port | 

| | | | | | | | 
MLI MLI MLI MLI 
| | | 

liaeaae oo cae eared | Saat cra 
| De 1| | DE: 1 | | DC 2| 
[Sao | jes | | [aS Ss5 | 
| | (De 222s S5Sses | (2eseees DC 6| 
PRs | [Sees | | [Seas | 
| Bee >| |-- De 6| | | Bcc | 
\ereSs | Jae | | [a | 
| | i i De aos Sea | | | PSM | 
|----- | | |[----- | || |----- | 
| | | | Bcc | | |--MLI--NSP 6| 
|----- | | |----- | | |----- | 
INSP 6--MLI--| | PSM | |----- MLI--NSP 7| 
[Soe = | Seaes | tetera | 
| | | LSP --datacomm lines | LSP--datacomm lines 


| | | LSP --datacomm lines | | 


|----- | |----- | |----- | 


| LSP --datacomm lines 


BCC = Base control card MLIP = Message-level Interface Processor 
DC = Distribution card NSP = Network Support Processor 

LSP = Line Support Processor PSM = Path Selection Module 

MLI = Message-Level Interface 


Figure 11. UIO Subsystem Configuration with Multiple Hosts 


Fach base must include a base control card (BCC). The BCC controls 
access to the DLPs by multiple hosts and also provides base 
identification information to the hosts upon request. 


Bases that contain more than one distribution card must include a Path 
Selection Module (PSM), which handles priority resolution and routing of 
messages being returned to the hosts. 


UIO Subsystem 


BASE IDENTIFICATION 


It is important that each base be uniquely identifiable so that a base 
accessed through multiple paths can be recognized as a single base. A 
base's identification number is derived from its maintenance 
identification number because each base must already have a unique 
identification number for maintenance purposes and because it is 
desirable for a processor and its maintenance processor to display the 
same identification number when referring to the same base. 


Every B 5900 or B 6900 processor has an associated maintenance 
processor. The maintenance processor is connected to a maintenance test 
bus, which allows maintenance routines to communicate with each base 
through a maintenance card (MC). Figure 12 represents a sample B 5900 
processor configuration, including the maintenance processor. 
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| ase a ican ce on a a | 
| B 59CO Processor 1| Maintenance | 
Processor --diskette 


|Port|Fort|Port|Port | 


MLI MLI 
| | | 

pela) [sel=+l 

bP De, | DC 1| | 

[peers | [SSser | 

| | | | 

[aS | [22sec | 

| BCC | | BCC | | 

(aa | oeiacasay | : 

| | | a 

SSeS | (a2=s= | : 

| °TP-DLP--TP | ODT-DLP--- | : 

Comme | Sere | 

|CR-DLP--CR | MT-DLP--MEC 

[aS | epee | : 

[HT-DLP--DPDC | | Maintenance 

| ----—— | [Haea= | Test Bus 1 

|MC2/1| |MC1/1| 

Tear |--:--| 
BCC = Base control care MEC = Master Electronic Control 
CR = Card reader MLI = Message-Level Interface 
DC = Distribution care MLIP = Message-Level Interface 
DLP = Data Link Processor Processor 
DPDC = Disk Pack Drive Controller MT = Magnetic tape 
HT = Host Transfer ODT = Operator Display Terminal 
MC = Maintenance card TP = Train printer 

Figure 12. B 5900 Prccessor and Maintenance Processor Configuration 


Every base must be 


connected 


to a maintenance test bus. Each 


maintenance test bus number must be unique within the entire system, and 


on a given maintenance test bus, 
each base can be uniquely identified by its maintenance test bus 


Thus, 
number and address. 


each base address must be unique. 


Fi 
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In the configuration above, the maintenance test bus numbered 1 connects 
to two bases, which have been assigned the maintenance test bus 
addresses 1 and 2. This is shown by the notations "1/1," indicating 
"address 1l/bus 1," and "2/1," indicating "address 2/bus 1." Note that 
the maintenance processor is shown connected to an Operator Display 
Terminal-DLP (ODT-DLP). This connection is required only if the 
maintenance processor's display terminal is also to function as an ODT. 
The maintenance processor configuration for a B 6900 system is 
Substantially different from this B 5900 processor configuration (see 
"B 6900 Maintenance Processor Configuration"). 


Each base includes a BCC, which will respond to a Test ID operation by 
returning a Jl6-bit, field-strappable base identification: 8 bits 
representing the maintenance test bus address of the base, 4 bits 
representing the maintenance bus number, and 4 bits that are currently 
unused and must be 0. 


See also 
B 6900 Maintenance Processor Configuration. .......... 85 
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DLP AND UNIT IDENTIFICATION 


The DLP ID is a 16-bit number with two components: 
oe An 8-bit, field-strappable base unit number 
Ze An 8-bit DLP type identification 


The DLP type identification specifies the type of the DLP (for example, 
a Magnetic Tape DLP (MT-DLP) or Card Reader DLP (CR-DLP)). The base 


unit number identifies the units connected to that DLP. Physical unit 
numbers are generated by asSigning to the first unit on the DLP a unit 
number equal to the base unit number. Each subsequent unit (or 


potential unit) is assigned the next higher number, as shown in Figure 
13 of an MT-DLP. 


|- MT Unit 48 
|- MT Unit 49 


|- MT Unit 51 


posse | [- MT Unit 54 


[| 48 | l= 


| | |- MT Unit 59 


l- MT Unit 63 


MEC = Master Electronic Control 
MT Unit = Magnetic tape unit 
MT-DLP = Magnetic Tape Data Link Processor 


Figure 13. Physical Unit Numbers Assigned According to Base Unit Number 


There must be a one-to-one correspondence between units and unit 
numbers; that is, multiple units cannot be assigned the same unit 
number. and multiple unit numbers cannot be assigned to the same unit. 
These rules imply the following restrictions on the assignment of DLP 
base unit numbers: 
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dis Base unit numbers for DLPs that connect to different units must 
be unique. 


2% Base unit numbers must be assigned such that there is no 
possibility for the range of potential unit numbers to overlap. 
For example, in a configuration that included the MT-DLP shown 
in Figure 13, a DLP could not be assigned a base unit number of 
62, because the range of possible unit numbers for units 
connected to MT-DLP 48 includes unit 62. 


ci The range of unit numbers that must be considered "occupied" 
for a given DLP depends on the type of DLP. 


4. All DLPs that connect to the same units through an exchange 


must have the same base unit number, so that the unit numbers 
generated for the units will be the same through all paths. 


The unit number O is not allowed to be assigned. 
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Table 6 shows the types of DLPs currently supported and the number 
potential units that can be configured behind DLPs of each type. 


Table 6. Supported DLPs and Maximum Units per DLP 


DLP | Peripheral |No. of Units 
cae reas ee ee ee eee eee 
| | 
CR-DLP | B9115/6/7 Card Reader | 1 
TP-DLP | 400-/750-/1100-/1500-lpm Train Printer| 1 
TP2-DLP | B9246-X Model Printers | 1 
TP3-DLP | B924 Model Drum Printer | . 
PT-DLP | B9246-X/B924 Model Printers 1 
| B9498 Streamer Tape 4 
MT-DLP | PE Tape | 16 
NRZ-DLP | 9-Track NRZ Magnetic Tape | 16 
GCR-DLP | GCR Magnetic Tape | 16 
CP-DLP | Card Punch | 1 
5NDF-DLP| 5N Disk file | 16 
HT-DLP | (Host Transfer) | 16 
| 225/235/206/207/659/677 Disk Pack | 
ODT-DLP | Operator Display Terminal | 3 
LSP-DLP | Datacomm lines | big 
NSP-DLP | Datacomm network (LSPs) | oe 
* Defined to be 1 for this purpose. LSPs and individual 
datacomm lines are selected by other means. 
CP = Card Punch NSP = Network Support Processor 
CR = Card Reader NRZ = NonReturn to Zero 
DLP = Data Link Processor ODT = Operator Display Terminal 
GCR = Group Coded Recording PE = Phase-Encoding 
HT = Host Transfer PT = Printer tape 
lpm = Lines per minut? cP = Train printer 


LSP = Line Support Processor 5SNDF = 5N disk file 
MT = Magnetic tape 
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UIO Subsystem 
PATH SPECIFICATION 
When requesting that an 1/0 be performed, PHYSICALIO selects a 


particular path by including the following information in the IOCB for 
the I/0: 


des The MLIP number 

Lx The MLI port number 

o's The Line Expansion Module (LEM) port number (described below) 
4. The DLP address (described below) 

De The relative unit number of the unit (that is, the DLP-relative 


offset of the unit) 


A unique base is identified by the combination of MLIP number, MLI port 
number, and LEM port number. An LEM provides the capability to expand 
one MLI into several, allowing multiple bases to connect to one MLI 
port. 


The DLP address is a number that identifies the DLP within the selected 
base. The DLP address is also used by the PSM to resolve conflicts when 
Multiple DLPs are ready to transmit data at the same time; DLPs with 
higher addresses have higher priority. 


For A 3, A 9, B 5900, and B 6900 systems, Table 7 indicates the current 
valid values for selection numbers. 


PHYSICAL 1/0 OVERVIEW 


Table 7. Valid Selection Numbers to Identify I/0 Path 
for A 3, A 9, B 5900, and B 6900 Systems 


! | B 5900 | Be6900 | A3 | AQ | 
Gan a a a a a al [Saree ae ASesasasS [Sos [Sr sorts | 
| | | | | | 
MLIP Number * | 1-4 | 1-4 | 1-7 | 1-7 | 
MLI Port Number | 0-3 | O-7 | o-2 | O-7 | 
LEM Port Number ** | O-7 | 0-7 | <@27. i O=7 | 
DLP Address | O-7 | O-7 | O=7 | OH? | 
Relative Unit Number ***| 0-15 | 0-15 | :O0325: f ~“O=15° 4 
i ah ge a Sac aed ee cht ae i ee ON eh epee See | 


* Matches the processor ID. 
** A LEM can have either 4 or 7 ports; the port numbers 
are in the range O through 7. 
*** Depends on DLP type; 15 is maximum for any DLP. 


For A 3K and A 10 systems, Table 8 indicates the current valid values 
for selection numbers. 


Table 8. Valid Selection Numbers to Identify 
I/O Path for A 3K and A 10 Systems 


| | A 3K | A 10 | 
SSeS eee Sen a [esas ie ee ae | 
| | | | 
| MLIP Number { 1-7 | 1-7 | 
i MLI Port Number | 0-2 | 0-7 | 
| LEM Port Number * | O-7 | O-7 | 
| DLP Address | O-7 | O-7 | 
| Relative Unit Number **| 0-15 | O-15 | 


* A LEM can have either 4 or 7 ports; 
the port numbers are in the range O through 7. 
** Depends on DLP type; 15 is maximum for any DLP. 


UIO Subsystem 


Figure 14 shows a disk unit reached by the path specified by MLIP 1, MLI 
port OO, LEM port 3, DLP address 2, relative unit 3. The disk unit is 
identified with [*] at the end of the figure. 


|Port|Port|Port|Port | 
| | | 


|Port{!Port|Port|Port|Port]|Port|Port | 
| | | | | | | 


2: |HT=DLP--—-- | --=-===---------- | 
a i DPDC | 
PMG i). “lease eeeeseeneaee | 
[Sqcaes | | Exchange | 
SSiaial lai 
aps ee te co 
O: 2:2 <3 4 248 AS 
[J 
BCC = Base control card LEM = Line Expansion Module 
CR = Card reader MC = Maintenance card 
De = Distribution card MLI = Message-Level Interface 
DLP = Data Link Processor MLIP = Message-Level Interface 
DPDC = Disk Pack Drive Controller Processor 
HT = Host Transfer TP = Train printer 


Figure 14. I/O Path from Processor to Disk Unit 
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In addition to the sath specifications described above, the IOCE 
contains the processo- ID of the processor that initiated the I/O. For 
A 3. A 9, B 5900, and 3 6900 systems, when an IOCB is unlinked from a 
result queue by PHYSICALIO, this processor ID is used to determine which 
processor is to finish processing the I/O. For A 3K and A110. systems, 
any processor can finish processing any I/O. 


See also 
PROCESS INS Of L/ OSs ok: eae Ge OR. A ees ed Se a A ee es .  E 
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B 6900 MAINTENANCE PROCESSOR CONFIGURATION 


A sample B 5900 processor configuration including a maintenance 
processor was illustrated in Figure 12. Although the maintenance test 
bus connects to the bases in the same manner on the B 6900 system as it 
does on the B 5900 system, the B 6900 maintenance processor requires 
access to some peripherals that are not required by the B 5900 
maintenance processor, necessitating some additional configuration 
restrictions for the B 6900 system. 


Because the B 6900 maintenance processor does not include a terminal for 
interacting with the system operator, the maintenance processor must 
have access to an ODT through an ODT-DLP. In addition, the maintenance 
processor requires access to a magnetic tape unit through an MT-DLP to 
load various programs and data (this information is accessed from a 
diskette on the B 5900 system). These DLPs must be located in the same 
base; this base is referred to as the "maintenance base" and is shown in 
Figure 15. 


Se 
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B 6900 Processor 1] Maintenance | 


| Processor | 
| sSssssessessSseaas |----|---:---- | 
MLIP | | 
Mae a a ache | | 
{Port|Port|Port|Port | | 
| | | | | 
MLI MLI MLI 
| | | 
[a ere | pasa Sosy) 1] 
i Dera | | Doll | 
[Sane | [Sees i | 
| | | pc 0 ---| 
(Saas | [-SSSS=s | : 
[. .BCe: ~4 | Bcc | Maintenance 
pPAecrseeses | [Sere [| “best Bust 
| | | PSM | : 
[ae | e2eeseS | 
| TP-DLP---TP | ODT-DLP--ODT 


| MC2/1 | | MC1/1 | 

Sas cee | ae eeea S| 
BCC = Base control card MC = Maintenance card 
DC = Distribution card MLI = Message-Level Interface 
DLP = Data Link Processor ODT = Operator Display Terminal 
DPDC = Disk Pack Drive Controller PSM = Path Selection Module 
HT = Host Transfer TP = Train printer 


Figure 15. B 6900 Processor and Maintenance Processor Configuration 


Because all B 6900 maintenance processors generate a Host Return field 
of O, a base can be the maintenance base for only one maintenance 
processor (because there can be only one distribution card 0). The 
maintenance test bus that: connects to a maintenance base must originate 
in the maintenance processor associated with that base. 


The maintenance base must be visible to (that is, shared with) only that 
processor associated with the maintenance processor. To simplify the 
path specification, there must not be a LEM on the MLI between the 
maintenance processor and itS maintenance base. 


87 


10 SYSTEM INITIALIZATION 


For the Master Control Program (MCP) on a Universal I/O (UIO) subsystem 
to begin system initialization, there must be valid bootstrap code. On. 
A 3, A 9, B 5900, and B 6900 systems, this bootstrap code is resident in 
the low addresses of memory. On A 3K and A 10 systems, the bootstrap 
code is loaded into memory from disk by the maintenance processor. The 
steps of the system initialization process, described below, begin at 
bootstrap code initialization. 


a The bootstrap code can begin executing because of a Halt/Load, 
a Change MCP (CM), a fatal tape dump, a reconfiguration 
command, or some other software cause. The bootstrap's main 


task is to initiate the GETITGOING procedure. The bootstrap 
has sufficient path information to perform I/Os to the 
Halt/Load unit, from which it reads the code for GETITGOING. 


ar GETITGOING reads in the necessary MCP data structures and 
"save" code. It also reads in and invokes all of the 
initialization procedures that select alternative modules based 
on the type of machine. These modules include PHYSICALIO 


(whose initialization procedure selects the PHYSICALIOHDP 
alternative for UIO subsystems), datacomm, maintenance, 
configuration control, and processor control. GETITGOING then 
calls PRIMARYINITIALIZE. 


ae PRIMARYINITIALIZE builds a more permanent stack for the MCP and 
moves to it, entering SECONDARYINITIALIZE in the process. 


4. SECONDARYINITIALIZE is the first procedure that recognizes the 
potential existence of other tightly-coupled processors. If 
there are multiple processors, one processor determines that it 
is the "leader" in the initialization process and coordinates 
the initialization of the other processors. The substeps of 
SECONDARYINITIALIZE describe the single-processor system; the 
multiple-processor system follows the same basic pattern, with 
the added complication of having to synchronize the leader and 
follower processors. 


After establishing its processor and memory environment, 
SECONDARYINITIALIZE calls PERIPHERALINITIALIZE. 


a. PERIPHERALINITIALIZE allocates space for I/O tables such 
as UNIT, UNITCONTROL, UNITMAP, and UNITSTATUS. It then 
calls PERIPHERALCONFIGURATOR with a parameter indicating 
that this call is from PERIPHERALINITIALIZE 
(PERIPHERALCONFIGURATOR is called at other times, such as 
when adding an outboard base and when freeing or acquiring 
a Data Link Processor (DLP)). PERIPHERALCONFIGURATOR then 
calls CONFIGPERIPHERALINITIALIZE. 
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be The main task of CONFIGPERIPHERALINITIALIZE is to loop 
through all possible Message-Level Interface (MLI) ports 
and Line Expansion Module (LEM) ports, issuing a TEST UNIT 
operation to each potential base (see the "UIO Subsystem" 
section for configuration requirements). When a base is 
found, CONFIGPERIPHERALINITIALIZE calls ADDABASE. 


Cy ADDABASE performs a TEST ID operation on each potential 

; DLP in the base, storing all of the resulting information 
in a bas? entry template that is to be merged into the 
configuration table. ADDABASF then calls MERGEBASEENTRY. 


om MERGEBASEENTRY determines whether or not there is already 
information in the configuration table about this base 
(for exanple, whether another processor has found it first 
or whether the base is described in the soft configuration 
file). If so, the base and DLP information derived by 
ADDABASE is merged in with the existing information (which 
may result in errors if the overlapping information is 
incompatible). If the base has not been seen before, a 
new base entry is added to the configuration table and 
ATDDANENTRYTOOTHERTABLES is called once for each DLP in the 
base. 


e. ADDANENTRYTOOTHERTABLES determines whether this DLF 
connects to units that have already been seen through 
another :sath or whether this DLP connects to new units. 
If the units have already been seen, ADDAPATH is called toa 
add the current path to the existing list of paths under 
the "path node" for those units. If the DLP connects toc 
new units. a new path node is entered in the path table, 
the current path is added to the path list, and each 
potential unit behind the DLP is assigned a physical and 
logical unit number and is added to the various physical 
and logical unit tables. If the units are of a type that 
cannot be configured behind a peripheral exchange (that 
is, if the units are “nonexchangeable") and if the units 
are of a type that requires peripheral status monitoring, 
STARTUNIT is called to start peripheral status monitoring 
for the units (see the "Peripheral Status" section). 


After PER“! PHERALINITIALIZE has been completed, 
SECONDARYINIT-ALIZE initiates the independent runners 
(including ETERNALIR and STARTSYSTEM), finishes the remainder 
of its processor synchronization code, and begins normal 
process switching. 


STARTSYSTEM is left to finish the high-level initialization of 
the system, including setting up the information required for 
Managing disk files. STARTSYSTEM calls ACQUIREUNITS to verify 
that there are no unit-ownership COnPlictrs among 


See also 
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loosely-coupled systems; if a conflict is detected, the 
initializing system will free the unit. In addition, 
ACQUIREUNITS attempts to acquire any exchangeable units that 
may belong to this group ina loosely-coupled environment. 
Once these units (if any) have been acquired, STARTSYSTEM calls 
PERIPHERALCONFIGURATOR (through SETUNITINFO) with a parameter 
indicating that peripheral status monitoring is to be initiated 
for all exchangeable units (see the "Peripheral Status" 
section). 


PeOrrpneral <SEACWS Le. ei ww. tee A aes WD a a ae ae ee Sa eS. Bee. OE 
UPO sSUBSYSEEIE fe <a Gok) ce fa er do ee, ee Se, RS ca Se SI a ok ae 
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il PERIPHERAL STATUS 


Monitoring a unit's peripheral ready/not-ready status is performed by 
issuing special TEST operations to each unit. There are four types of 
TEST operations involved: 


nie TEST UNIT 
a TEST/WAIT FOR READY 
3 TEST/WAIT FOR NOT READY 


4. TEST/WAIT FOR TRANSMIT (valid only for Operator Display 
Terminals (ODTs) ) 


A TEST UNIT operation will finish "“immediately" (that is, without 
waiting), returning identification and status information for the unit 
to which it was directed. In contrast, a TEST/WAIT operation to a unit 
will not finish until the unit's status matches the status specified 
(for example, becomes "ready," in the case of TEST/WAIT FOR READY); the 
I/O Finish interrupt for a TEST/WAIT operation notifies the system that 
the unit requires attention, as its status may have changed. 


Most types of devices are monitored by alternating TEST/WAIT FOR READY 
operations with TEST/WAIT FOR NOT READY operations. However, the 
peripheral status monitoring process must take into account a few device 
dependencies. First, peripheral status is not monitored for devices for 
which it is not meaningful, such as Network Support Processors (NSPs) 
and Line Support Processors (LSPs). Second, ODTs are monitored with 
TEST/WAIT FOR TRANSMIT operations, instead of TEST/WAIT FOR READY and 
TEST/WAIT FOR NOT READY operations, because of the nature of the device. 


The maintenance of valid peripheral status information depends on the 
issuing of an initial TEST/WAIT operation when the unit first becomes 
visible to PHYSICALIO. During system initialization, peripheral status 
monitoring is initiated for nonexchangeable devices by 
ADDANENTRYTOOTHERTABLES and, later, for exchangeable devices by 
STARTSYSTEM. When a unit is taken from PHYSICALIO's control (through 
TAKEUNIT), monitoring of peripheral status is stopped; when the unit is 
returned, GIVEUNIT reinitiates peripheral status monitoring if requested 
by the appropriate parameter value. Other processes by which units may 
become visible, such as through the ODT commands ACQUIRE and UR-, also 
include initiation of peripheral status monitoring. 


Once the first TEST/WAIT operation has been issued, the process is 
self-sustaining (a new TEST/WAIT operation being issued whenever the 
current one completes) until monitoring is canceled for some reason (for 
example, by the ODT commands UR and FREE). The following sequence of 


PHYSICAL I/O OVERVIEW 
events occurs whenever a TEST/WAIT operation has completed: 


1% IOFINISH68 or IOFINISH_ASIO is called by HARDWAREINTERRUPT to 
handle the 1/0 Finish interrupt. When IOFINISH68 or 
IOFINISH_ASIO determines that the I/O that finished is a 
peripheral status monitoring operation, IOSTATUS is called. 


Bs If the completed TEST operation is a TEST/WAIT FOR TRANSMIT 
operation, IOSTATUS initiates KEYIN to handle the operator 
input and to initiate a new TEST/WAIT FOR TRANSMIT operation. 
If the TEST operation was a TEST/WAIT FOR READY or TEST/WAIT 
FOR NOT READY operation, IOSTATUS determines whether or not the 
device has actually changed logical or physical status; if so, 
IOSTATUS updates the UNITSTATUS table to reflect the new status 
of the device, queues a message for PHYSICALPERIPHERALSTATUS 
indicating that the unit's status has changed, and initiates a 
new TEST/WAIT operation to wait for the opposite status 
condition. 


Note 


If an exception occurs, such as a 
TEST/WAIT FOR READY operation finishing 
with a NOT READY peripheral status, the 
unit is marked logically NOT READY and 
peripheral status monitoring for that 
unit ceases. 


PHYSICALPERIPHERALSTATUS is called by ETERNALIR either when the MCP 
requests that it be called due to a status change on a unit, or 
approximately once every second. in other words, 
PHYSICALPERIPHERALSTATUS is called either on demand or at regular 
intervals. PHYSICALPERIPHERALSTATUS reads each message in its queue, 
taking one or more of the following actions as appropriate: 


1. If the message indicates that peripheral status monitoring is 
to start for a unit (for example, if GIVEUNIT queues such a 
message), DOSTATUSIO is called to initiate a TEST/WAIT 
operation of the type specified in the message. 


Ze If peripheral status monitoring is to stop for a unit (for 
example, if TAKEUNIT queues such a message), DOSTATUSIO is 
called to cancel the current TEST/WAIT operation on the unit. 
Because the command queue for the unit is marked "Suspended" 
when a TEST/WAIT operation is initiated, DOSTATUSIO initiates a 
cancel or disconzinue operation with an IOCB with the Immediate 
field in the MLI?® Control Word (Word 0) set to TRUE, causing 
the MLIP to initiate the cancel operation regardless of the 
fact that the command queve is suspended. When the TEST/WAIT 


Peripheral Status 


operation has been canceled, DOSTATUSIO initiates an MLIP 
Activate Queue command to reset the Suspended field for the 
command queue. 


If the message indicates that a peripheral’s status has 
changed, LOGICALPERIPHERALSTATUS is called. 
LOGICALPERIPHERALSTATUS updates the status for the unit in the 
UNIT table and takes other action as appropriate based on the 
unit's type and its current status. For example, if a magnetic 
tape unit changes status from not ready to ready, READALABEL is 
initiated. 
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12 DATA COMMUNICATIONS 


Data communications operations are handled by three special-purpose Data 
Link Processors (DLPs): the Network Support Processor (NSP), the Line 
Support Processor (LSP), and the Data Communications Data Link Processor 
(DC-DLP). This section describes these DLPs and the functions provided 
by the DCCONTROL and PHYSICALIO modules of the Master Control Program 
(MCP) to support data communications. 


NSPs, LSPs, AND DC-DLPs 


NSPs and LSPs are programmable DLPS that provide data communications 
services. Both are programmed using the Network Definition Language II 
(NDLII). LSPs run the Adaptor Control portion of the NDLII code, and 
NSPs run the Editors and Line Control portions of the NDLII code. 


Each DLP also runs an Executive program. The NSP Executive maintains a 
dialog with an MCP process called DCCONTROL and with the LSPs it 
controls. The LSP Executive supports the dialog with the NSP. DC-DLPs 
are NSPs that have built-in LSPs. DC-DLPs are not programmable with 
NDLII and only run specific protocols. The MCP communicates with 


- DC-DLPs in the same manner as do NSPs. 


For its configuration tables, PHYSICALIO considers NSPs, LSPs, and 
DC-DLPS to be single-unit DLPs. Message routing to a particular LSP, 
line, and station is performed by the NSPs, LSPs, and DC-DLPs 
themselves. Although all LSPs must be in bases that are visible to 
their controlling NSPs, they need not be in bases that are visible to 
the host. NSPs act as "outboard hosts," providing an indirect 
communication path between the LSPs and the host (see the “UIO 
Subsystem" section for a configuration diagram that includes NSPs and 
LSPs). Because LSPs may be "invisible" to the host during system 
initialization, PHYSICALIO must be able to add LSPs to its tables as 
datacomm is being initialized. 


See also 
ULO-SUDSY SOM ae: acta £. Say Goes Get RM Gh eat et ee a Se es 4 OE Re ee ee. 9S 
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DATACOMM I/O REQUESTS 


A typical datacomm I/O request from a user program follows a path 
schematically similar to the following: 


program -> DCCONTROL -> PHYSICALIO -> UIO subsystem 


The datacomm I/O request (for example, a read or a write) is passed to 
the MCP DCCONTROL process, which calls a PHYSICALIO interface procedure 
to initiate the actual I/0 operation. From PHYSICALIO to the 
destination terminal, th2 I/O can follow the following paths: 


PHYSICALIO -> MLIP -> NSP -> LSP -> terminal 


| | 
|= DEADLP’ ==541 


The 1/0 is passed to the Message-Level Interface Program (MLIP), which 
routes the request to the NSP. The NSP then sends a request through a 
Message-Level Interface (MLI) to the LSP that controls the line 
connected to the terminal. 


This transmission process involves many levels of communication. For 
example, at a basic level, the NSP communicates with the LSP over an 
MLI; at a higher level, the NSP communicates control information and 
data to the LSP through the messages transmitted over the MLI. 
Similarly. DCCONTROL initiates normal I/O operations through PHYSICALIO 
to the NSP; at a higher level, the data transferred by these I/0 
operations is used to maintain a request/response dialog between 
DCCONTROL and the NSP. 
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DATACOMM INITIALIZATION 


There are several conditions that will cause datacomm to be initialized, 
including the entering of certain Operator Display Terminal (ODT) 
commands and the setting of some system options. When datacomm is to be 
initialized for an NSP or DC-DLP, the MCP process DCCONTROL is 


initiated. (There is a separate activation of DCCONTROL for each NSP; 
for simplicity, only a single activation is described here.) DCCONTROL 
calls DCINITIAL to begin the initialization. DCINITIAL performs the 


following steps: 


a DCINITIAL first calls procedures in the DATACOMSUPPORT library 
to build the datacomm tables. 


Ca DCINITIAL then calls the PHYSICALIO procedure INITIALIZEDCLCP 
to load the NSP firmware. 


ae Once the NSP firmware has been loaded, ADDANOUTBOARDBASE is 
called; it performs TEST operations through the NSP to the base 
containing its LSPs so that the LSP base can be added to the 
configuration tables. 


As Next, DCINITIAL allocates two Input/Output Control Blocks 
(IOCBs): one is used tc transmit the NSP requests required to 
establish the network configuration and to load the NDLII code 
from the DATACOMINFO file, and the other is used to receive the 


NSP's acknowledgments of the requests. These I/Os are 
initiated through the PHYSICALIO interface procedure 
INITIATECHARIO. 


DCCONTROL then calls SCIOINITIALIZE to set up the I/0 structures for 
normal operation. 


During normal operation, each NSP has three allocated command queues. 
One of these queues is for read operations. The other two queues are 
used for write operations, one for normal output and one for control. 
Each queue has an active limit of one. 


SCIOINITIALIZE allocates a large number of IOCBs and input buffers of 
various sizes for read operations; these IOCBS are then initiated, 
through INITIATECHARIO, into the input command queue. Additional I10OCBs 
are allocated for output operations, but are not initiated until 
required. 
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Prior to beginning normal operation, DCCONTROL calls DCPCONTROLLER to 
process any spontaneous input messages that were received during the 
initialization phase. 


Data Communications 


NORMAL DATACOMM OPERATION 


A typical request/response cycle requires two physical I/Os: a write to 
send the NSP request and a read to receive the NSP response. For 
example, to perform a write to a terminal, DCCONTROL would initiate an 
IOCB with the following information in the I/O buffer: 


| NSP Request | Identification | NDLII Program | Data for the | 
| Information | Tag | Control Terminal | 
|(for example, | | Information | | 
| WRITE) | | | 


When the NSP has received the request through the MLI, it sends a DLP 
result to the MLIP; the MLIP stores the result information, and 
FINISHOFFIO causes the event specified in the IOCB, which notifies 
DCCONTROL only that the NSP has received the request. The NSP then 
transfers the data for the terminal to the LSP in a message that also 
contains LSP control information. When the data has been written to the 
terminal, the LSP returns a result to the NSP. The NSP then formats a 
result message and sends it to the system. Multiple results can be 
transferred to the I/O buffer. The data returned includes the following 
information: 


| NSP Result | Identification | NDLII Program | 
| Information | Tag | Result | 
| | | Information | 


When this I/O completes, DCCONTROL uses the identification tag to 
associate the response with its corresponding request and calls 
DCPCONTROLLER to return the result information to the requesting 
program. 


In steady-state operation, DCCONTROL uses the "POBOX" mechanism to wait 
for one of several conditions to happen. The POBOX mechanism allows a 
process to assign an identifying “signature” to each of an arbitrary 
number of events, called "MEMOs." The process then monitors its POBOX 
until one of two conditions occurs: a MEMO is received, indicating that 
the event associated with that MEMO has happened, or a specified timeout 
period elapses. MEMOs are queued, if necessary, and are returned to the 
process in chronological order of their happening. Based on the 
Signature, the process takes the appropriate action for each MEMO. 
DCCONTROL asSigns MEMOs for the following events: 
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- Completion of a write operation 
- Completion of a read operation 
- Queuing of an I/0 request from a program 


- The DCCONTROL stack's EXCEPTIONEVENT 


When a write operation completes, DCCONTROL notes that the I/O was 
completed and deallocates the data buffer but takes little additional 
action until the read of the NSP result completes. 


When a read operation is complete, DCCONTROL examines each of the 
messages in the input buffer. If a message indicates that a requested 
operation is now complete, DCCONTROL calls DCPCONTROLLER to pass the 
result information to the requesting program. At this point, DCCONTROL 
can initiate writes to the NSP for previously requested actions that 
were queued until the proper conditions existed. 


When an I/O request is queued, DCCONTROL interprets the request and 
initiates the appropriate I/0(s) or queues the request itself for later 
action. 


When DCCONTROL's EXCEPTIONEVENT is caused, DCCONTROL analyzes its 
TASKVALUE to determine what action to take. If an NSP dump is 
requested, DCCONTROL calls the PHYSICALIO procedure DUMPDCDLP. Lf 
termination of datacomm was requested, DCCONTROL calls SCIOSHUTDOWN, (as 
described in “Datacomm Termination"), and then terminates. 


When no MEMOs are received, DCCONTROL unconditionally waits 
140 milliseconds and then processes any queued MEMOs. If there are no 
MEMOS queued, DCCONTROL waits ten seconds for a MEMO to be queued. If a 
MEMO is not queued in ten seconds, a null request message is sent. 
After the third consecutive null request message is sent with no MEMO 
received, DCCONTROL displays a message indicating that the NSP is not 
responding. 


see also 
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DATACOMM TERMINATION 


Termination of a datacomm process can result from any one of several 
operator input messages. When DCCONTROL detects that it has been 
terminated, it calls SCIOSHUTDOWN. SCIOSHUTDOWN calls BLASTUNIT to 
cancel all outstanding I/Os and returns canceled results to _ the 
requesting program(s). DCCONTROL then calls DCTERMINATE, which’ gives 
PHYSICALIO control (through GIVEUNIT) of the NSP and its LSPs, returns 
program requests that were queued waiting for initiation, and 
deallocates all message areas. If the last DCCONTROL process is 
terminating, DCTERMINATE also deallocates all datacomm tables. 


GLOSSARY 


base 
A hardware unit in the Input/Output (I/0) subsystem that contains 
the components necessary for handling the routing of messages 
between the Data Link Processors (DLPs) and the host processor 
through the Message-Level Interface Processor (MLIP). The base 
itself contains at least one DLP. 

base control card (BCC) 
A base module that identifies a base and controls access to its Data 
Link Processors (DLPs) and to the base itself. 


BCC 


See "base control card." 


Card Reader Data Link Processor (CR-DLP) 
A processor that serves as the controller of a card reader and 
provides the I/O interface between the system and the card reader. 
Change MCP (CM) 
An Operator Display Terminal (ODT) command that specifies a 
particular Master Control Program (MCP) code file on an optionally 
specified disk pack family as the MCP code file to be used at the 
next Halt/Load. 


CM 


See "Change MCP." 


Communicate with Universal I/O (CUIO) 


An operator that passes the address of an I/O Control Block (IOCB) 
to the Message-Level Interface Processor (MLIP) for initiation. 
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CR-DLP 


See "Card Reader Data Link Processor." 


CUIO 


See "Communicate with Universal I/0." 


DATACOMINFO file 


A file that contains a complete description of the datacomm 
configuration, including algorithms, editors, and translate tables. 
This is the file that the Interactive Datacomm Configurator (IDC) 
modifies and from which the Master Control Program (MCP) initializes 
the data communicat:ons subsystem. 


Data Communications Data Link Processor (DC-—DLP) 
A data communications processor that combines the functions of the 
Network Support Processor (NSP) and Line Support Processor (LSP) 
into one physical Data Link Processor (DLP) and supports up to four 
lines of communicat:.on. 

Data Link Processor (DLP) 
A processor that serves as the controller of one or more peripheral 
devices or data communications lines and provides the interface 
between the system and the peripherals and lines. 

Data Link Processor Address Word (DLPAW) 
Contains several fields used by the Message-Level Interface 
Processor (MLIP) to address a Data Link Processor (DLP). 


DC 


See "distribution card." 
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DC--DLP 


See "Data Communications Data Link Processor." 


Disk Pack Drive Controller (DPDC) 
An interface between the Data Link Processor (DLP) and disk pack 
units. 

distribution card (DC) 


A base module that acts aS an interface between a host and a base. 


DLP 


See "Data Link Processor." 


DLPAW 


See "Data Link Processor Address Word." 


DPDC 


See "Disk Pack Drive Controller." 


EMP 


See "E-Mode Processor." 


EMP Destination Set (EMPDS) 
Contains the destination set of E-Mode processors that are signaled 
when an I/O has finished. 

EMPDS 


See "EMP Destination Set (EMPDS)." 
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E-Mode Processor (EMP) 


The central processing unit in Burroughs E-Mode architecture. 


FIB 


See "File Informaticn Block." 


File Information Block (FIB) 


Contains information about the user I/O that is passed to the 
PHYSICALIO module. 


GCR-DLP 


see "Group Coded Recording Data Link Processor." 


Group Coded Recording Deta Link Processor (GCR-DLP) 
A processor that serves as the controller of a Group Coded Recording 


(GCR) magnetic tape drive and provides the I/O interface between the 
system and the GCR nagnetic tape drive. 


Halt /Load 


A process that starts or restarts the Master Control Program (MCP). 


See "Host Data Unit." 


Host Data Unit (HDU) 


The B 7900 or A 15 system host interface to the Input/Output (I/0) 
subsystem. An HDU is configured with three host-dependent ports, 
each of which supports two Message-Level Interface (MLI) cables. A 
B 7900 or A115 host processor can have more than one HDU. The 
B 7900 and A 15 systems are called "HDU machines." 
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Host Transfer Data Link Processor (HT-DLP) 
A processor that communicates information to the Disk Pack Drive 
Controller (DPDC) that interfaces up to 16 disk drive units. 
HT—DLP 


See "Host Transfer Data Link Processor." 


input/output (1/0) 
An operation in which the system reads data from or writes data to a 
peripheral device such as a disk drive. 

Input/Output Control Block (IOCB) 
A data structure used for communication between the host system and 
the Message-Level Interface Processor (MLIP). 

Input/Output Control Word (IOCW) 
Area in the IOCB where information about the I/O to be performed 
resides. 

IOCB 


See "Input/Output Control Block." 


IOCW 


See "Input/Output Control Word." 


I/O 


See "input/output." 
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LEM 


See "Line Expansion Module." 


Line Expansion Module (LEM) 


A hardware module that allows the attachment of several bases to a 
single Message-Level Interface Processor (MLIP) port. 


Line Support Processor (ISP) 
On Message-Level Interface Processor (MLIP) systems, the data 
communications subsystem processor that manages communication with 


the host and initiates processes that control the input of messages 
to and output of messages from data communications lines. 


1pm 
Acronym for “lines per minute" used when describing the printing 
speed of a train printer. 

LSP 


See “Line Support Processor." 


Magnetic Tape Data Link Processor (MT-—DLP) 


A processor that serves as the controller of a magnetic tape drive 
and provides the {/O0 interface between the system and the tape 
drive. 


Maintenance card (MC) 


A base module that acts as an interface between a maintenance test 
bus and a base. 


Master Control Program (MCP) 


The operating system on A Series and B 5000/B 6000/B 7000 Series 
systems: the program that controls the operational environment of 
the system. This control includes memory management, job selection, 
peripheral management, system utilization, program segmentation, 
Subroutine linkage, and error logging. 
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Master Electronic Control (MEC) 


An interface between the Magnetic Tape Data Link Processor (MT-DLP) 
and the magnetic tape (MT) units that the MT-DLP supports. 


MC 

See "Maintenance card." 
MCP 

See "Master Control Program." 
MEC 


See "Master Electronic Control." 


Message-Level Interface (MLI) 
The interface between the host system and the input/output (1/0) and 
data communications subsystems. 

Message-Level Interface Processor (MLIP) 
The input/output (I/0) processor associated with a central processor 
Unit. 

Message-Level Interface Processor Destination Set (MLIPDS) 


Contains the destination set of MLIPs that can be signaled for I/0 
initiation. 


See "Message-Level Interface." 
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MLIP 


See "Message-Level Interface Processor." 


MLIPDS 


See "Message-Level Interface Processor Destination Set." 


MT-DLP 


See "Magnetic Tape Data Link Processor." 


NDLII 


See "Network Definition Language II." 


Network Definition Language II (NDLII) 
The Burroughs language used to describe the physical, logical, and 
functional characteristics of the data communications subsystem on 
Message-Level Interface Processor (MLIP)/Host Data Unit (HDU) 
systems. 

Network Support Processor (NSP) 
On Message-Level Interface Processor (MLIP) systems, the data 
communications subsystem processor that controls the MLIP. 

New Programming (NEWP) language 
A structured, high-level programming language used in developing 
some of Burroughs system software. 


NEWP 


See "New Programming (NEWP) language." 
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NonReturn to Zero Data Link Processor (NRZ-DLP) 
A processor that serves as the controller of a NonReturn to Zero 
(NRZ) tape drive and provides the I/O interface between the system 
and the NRZ tape drive. 
NRZ-—DLP 


See "NonReturn to Zero Data Link Processor." 


NSP 


See "Network Support Processor." 


ODT 


See "Operator Display Terminal.” 


ODT—-DLP 


See "Operator Display Terminal Data Link Processor." 


Operator Display Terminal (ODT) 


The system console device that allows the operator to enter commands 
directly to the operating system to perform various functions. 


Operator Display Terminal Data Link Processor (ODT-DLP) 


A processor that serves as the controller of an Operator Display 
Terminal and provides the I/O interface between the system and the 
Operator Display Terminal. 


Path Select Module (PSM) 


The state of the CANDE input queue after the original executing 
command has’ finished. At that time, a CANDE "?GO", "?WAIT", 
"?PURGE", "?TAKE", or "“?ENTER" command can be entered to manipulate 
the queue, or the queued input can be discarded by entering any 
other CANDE command. 
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PE-DLP 


See "Phase-Encoding Data Link Processor." 


Phase-Encoding Data Link Processor (PE-DLP) 
A processor that serves as the controller of a Phase-Encoding (PE) 
tape drive and provides the I/O interface between the system and the 
PE tape drive. 

PSM 


See "Path Select Module." 


Signal Processing Element: Set (SPES) operator 


An operator that signals an MLIP for I/O initiation. 


SPES operator 


See "Signal Processing Element Set (SPES) operator." 


TP-DLP 


See "Train Printer Data Link Processor." 


Train Printer Data Link Processor (TR-DLP) 
A processor that serves as the controller of a train printer and 
provides the I/O interface between the system and the printer. 

UIO 


See "Universal Input,/Output." 


unit 


A peripheral device such as a disk drive. 
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Unit Reserved (UR) 
An Operator Display Terminal (ODT) command used to reserve a unit 
identified by a device name and unit number. The "-" option 
restores the unit identified by the device name and unit number. 
Universal Input/Output 
The input/output (1/0) subsystem that manages all transfers of 
information between the operating system and peripheral devices. 
UR 


See "Unit Reserve (UR)." 


UR- 


See "Unit Reserve (UR)." 


WATI operator 


WATI is a mnemonic for "read machine identification." The WATI 
operator identifies the system in use and determines which I/0 
method is to be used. 


Index 


Base control card (BCC), 74 
BUILDIOCB, 16 
BUILDLOGICALRD, 26 


Command queue, 30, 42 
Head IOCB Link, 43 
Horizontal Queue Head Pointer, 43 
Horizontal Queue Link, 43 
Queue Control Word, 42 
Active Count, 42 
Active Limit, 42 
Command Queue Header Mark, 42 
Horizontal Queue Present, 43 
Inactive Count, 42 
Suspended, 42 
Waiting, 43 
Tail IOCB Link, 43 
Communicate with Universal I/0, See CUIO operator 
Configuration table, 88 
CUIO operator, 30, 39 


Data communications operations, 95 
datacomm I/O requests, 96 
datacomm initialization, 97 
datacomm termination, 101 
DLP types 


Data Communications Data Link Processors (DC-DLP), 


Line Support Processor (LSP), 95 
Network Support Processor (NSP), 95 
normal datacomm operation, 99 
Data Link Processor, See DLP 
Data structures 
command queue, 42 
for A 3, A 9, B 5900, and B 6900 systems, 30 
for A 3K and A 10 systems, 31 
horizontal queue, 58 
FOCE: 25 
IOCB I/O table, 33 
IOCB queue, 41 
MLIP I/O table, 56 
result queue, 60 
shared, 29 
unit queue, 48 
Datacomm, See Data communications operations 
DCCONTROL, 95 
Descriptor link, See MLIP/UIO interface 
Disk seek optimization, 32 _ 
Distribution card (DC), 73 
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address, 8l 

card reader, 10 

host transfer, 10 

train printer, 10 

types, 95, See also Data communications operations 
DO procedures, 17 


EMP destination set, 3l 
Exception handling, 26 


Horizontal queue, 58 
Host return field, 71, 73 


1/0 
exception handling, 26 
Finish interrupt, 62 
mask, 26 
processing, examples of 
for A 3, A 9, B 5900, and B 6900 systems, 22 
for A 3K and A 10 systems, 23 
Identification number 
base, 75 
Maintenance, 75 
Initialization, system, See System initialization procedures 
INITIATE procedures, 17 
Input/Output Control Block, See IOCB 
Invalid Operand interrupt, 39 
LOCB, 15, 33 
Command or Unit Queue Header Pointer, 37 
DLP Address Word, 37 
DLP Command/Result Lengths, 37 
DLP I/O Command Pointer, 37 
DLP I/O Result Pointer, 37 
I/O Finish Time, 39 
I/O Start Time, 39 
MLIP Control Word, 34 
Attention, 34 
Cause I/O Finish Interrupt, 34 
Continue Count at End of Length, 35 
Disk Seek Optimization, 36 
Don" i: -Count.,. +36 
Ignore Count Error, 36 
Ignore Suspend Ail Queues, 36 
Immediate, 36 
Input, 35 
IOCB Mark, 34 
Memory Direction, 35 
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TOCB: eont +) 
Memory Override, 35 
MLIP/DLP Command, 34 
OuUtpUL,: “35 
Output Zeros, 35 
Queue at Head, 34 
Simple Path Selection, 36 
Tae Control, 35 
Word-Oriented Transfer, 35 
MLIP Current Data Area Pointer, 38 
MLIP Current I/O Length, 38 
MLIP State and Result, 38 
Attention, 38 
Completed After Queue Suspended, 39 
DLP Error, 38 
Exception, 38 
MLIP Not Available, 39 
MLIP/Hardware Error, 39 
MLIP/MLI Error, 38 
Next IOCB Link, 37 
Result Mask, 37 
Result Queue Head Pointer, 37 
Self Pointer, 37 
IOCB I/O table, 33 
IOCB interface procedures, 15 
IOCB queue, 41 
IOCB Queue 
Control Word, 41 
Head, 41 
Tail, 41 
IOERROR, 26 
IOEXCEPTION, 26 


Line Expansion Module (LEM) port number, 81 


Maintenance card, 75 
Maintenance test bus, 75 
MCP I/O requestor 


main sets 
Kernel, 12 
Maintenance, 12 
MCP, 12 
User, 12 
types of modules, 11 
MEMO. 99 
Message-Level Interface Processor, See MLIP 
MLIP, 65 
commands 


Activate Queue, 66 
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MLIP (cont. ) 
Clear DLP Status, €7 
Deactivate Queue, 66 
Decrement Unit Active Limit, 69 
Discontinue Error IOCB, 66 
General Clear, 68 
Increment Unit Active Limit, 69 
Read DLP Status, 67 
Read MLIP Status, 67 
Reset the Suspend All Queues Flag, 66 
Return Active IOCB, 68 
Return Queue, 67 
Set I/O Table EMPDS, 68 
Set I/0 Table MLIPDS, 68 
Set the Suspend Al] Queues Flag, 66 
Set Unit Queue I/O Optimization Word 2, 69 
Set Unit Queue Path Word, 68 
Wait for Error, 65 
destination set, 31 
error handling, 63 
I/O subsystem, 1 
I/O subsystem overview, 7 
systems, l 
MLIP I/O table, 56 
EMP Destination Set, 57 
IOCB Queue Head Pointer, 56 
MLIP Destination Set, 57 
MLIP I/O Table Control] Word, 56 
MLIP Queue Control Word, 56 
Lock Bit, 57 
MLIP Queue Mark, 57 
MLIP Queue Head Unit Queue Link Data Descriptor, 
MLIP Queue Tail Unit Queue Link Data Descriptor, 
MLIP Scratch Area Word O through Word 9, 57 
MLIP Suspend All Queues field, 36 
MLIP/UIO interface, 71 
descriptor link, 71 


Network Definition Language II (NDLII), 95 


Path Selection Module (PSM), 74 
Feripheral status, test operations for 
TEST UNIT, 91 
TEST/WAIT FOR NOT READY, 91 
TEST/WAIT FOR READY, 1 
TEST/WAIT FOR TRANSMIT, 91 
Physical I/0 
major components of, |; 
Standard path for, 7 
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PHYSICALIO module, 11, 21 
PHYSICALIO/MLIP interface, 29, 33 
PHYSICALIO/MLIP mechanisms 
A 3, A 9, B 5900, and B 6900 systems, 29 
A 3K and A 10 systems, 31 


Requestor/PHYSICALIO interface, 15 
Requestors, MCP, See MCP I/O requestor 
Result queue, 60 


Signal Processing Element Set (SPES) operator, 29 
SPES operator, See Signal Processing Element Set (SPES) operator 
System initialization procedures, 87 

ACQUIREUNITS, 88 

ADDABASE, 88 

ADDANENTRYTOOTHERTABLES, 88 

CONFIGPERIPHERALINITIALIZE, 87 

GETITGOING, 87 

MERGEBASEENTRY, 88 

PERIPHERALCONFIGURATOR, 87 

PERIPHERALINITIALIZE, 87 

PRIMARYINITIALIZE, 87 

SECONDARYINITIALIZE, 87 

STARTSYSTEM, 88 


UIO 
bases, 9 
hardware configuration, 9 
overview, 9 

UIO bases, 9 

UIO subsystem, 73 

UIO subsystem configuration 
configuring B 6900 maintenance processor, 85 
identifying base, 75 
identifying DLP and unit, 78 
identifying host, 73 
specifying paths, 8l 

Unit information modules 
FILEFINDER, 14 
MCPSTATUS, 14 
UNITID, 14 

Unit information tables 
UNITCONTROL, 28 
UNITMAP, 28 
UNITSTATUS, 28 

Unit interface procedures 
GETLOGICALUNITSTATUS, 20 
GETUNITINFO, 20 
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Unit interface procedur2s (cont.) 


GIVEUNIT, 19 
SETUNITINFO, ZO 
TAKEUNIT, 19 
Unit number 
logical, 19 
physical, 19 
Unit queue, 48 


Dynamic Unit Que 
Head IOCB Link, 
Horizontal Queue 
I/O Optimization 
Bypass Court, 
Bypass Limit, 
Disk Address, 
Maximum IOCBs 
Physical Inte 
I/O Optimization 
Cylinder Size 
Minimum Diffe 
Last IOCB Initia 
Path Table Point 


Queue Control Word, 


Active Count, 
Active Limit, 
Connection in 
Horizontal Qu 
Inactive Coun 
Lock Bit, 50 
Path Selected 
Suspended, 49 
Unit Queue He 
Waiting, 49 
Waiting in ML 
Spare, 50 
Tail IOCB Link, 
Unit—-Related Fat 
Unit DLP Mask 
Unit queue header, 
Universal Input/cut 


WATI operator, 21 
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to Examine, 50 
grity Check, 50 
Word 2, 51 
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Progress, 49 
eue Present, 
t, 48 


49 


» 49 

ader Mark, 48 
IP Queue, 50 
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h Information, 
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